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Prefacio 


Rubiana Rosa 


Em 2016, o nosso time de engenheiros de suporte da Microsoft teve 
a fantástica e gratificante experiência em poder compartilhar seu 
conhecimento, as melhores práticas de desenvolvimento, através da 
publicação do nosso primeiro livro chamado Desenvolvimento 
efetivo na plataforma Microsoft: Como desenvolver e suportar 
software que funciona. 


Naquela ocasião, recebemos inúmeros feedbacks sobre como era 
importante ter um livro feito por desenvolvedores para 
desenvolvedores, e como o livro havia contribuído positivamente 
com a enorme comunidade técnica no Brasil. Isso nos incentivou a 
seguir adiante e a pensar na publicação de um segundo livro. 


Durante esse período, muitas coisas mudaram, evoluíram. É sempre 
impressionante pensar que nos últimos cinco anos direcionamos 
nossos esforços e trabalhos para suportar nossos clientes no 
desenvolvimento e migração de suas aplicações para a nuvem. Nós 
nos preparamos para dar suporte aos nossos clientes para que eles 
consigam tirar o maior e melhor proveito do investimento feito em 
nossa plataforma. 


Trabalhamos no advento de migrações e no desenvolvimento das 
aplicações, atendemos a milhares de clientes mundiais e pudemos 
observar que a transformação digital, a modernização e a migração 
para a nuvem são um caminho que para muitos ainda pode parecer 
distante, mas que, por outro lado, pode ser planejado e percorrido 
de modo rápido e seguro. 


Decidimos então escrever nosso segundo livro com o objetivo de 
compartilhar a experiência do time de engenheiros de suporte da 
Microsoft, para guiar pessoas pelo caminho para a nuvem com 
sucesso! Certamente os nossos clientes poderão ter o retorno dos 


seus investimentos fazendo uso de técnicas e por meio da 
experiência de se ter um planejamento de modernização e migração 
e um desenvolvimento efetivo, que os permitam ter suas aplicações 
rodando na nuvem de maneira segura, escalável e ágil. 


É um orgulho enorme poder fazer parte de um time que está sempre 
se atualizando, buscando o que há de mais moderno para os 
clientes e para a nossa comunidade técnica. Em um mundo onde a 
tecnologia muda tão rápido, ter esse compromisso com a 
atualização tecnológica é um desafio que o time de engenheiros de 
suporte da Microsoft gosta de enfrentar e compartilhar. 


Espero que vocês aproveitem este novo livro, feito com dedicação, e 
que embarquem conosco nesta jornada para desenvolver suas 
aplicações seguindo as melhores práticas para que funcionem com 
sucesso na nuvem! 


Rubiana Dalla Rosa, cloud solution architect manager, Apps & Infra, 
Microsoft 


Scott Guthrie 


The developer community has the unique opportunity to define the 
future. This book, written for developers by developers, explores 
concepts and tools that businesses and organizations of all sizes 
can adopt to modernize their applications on Microsoft Azure and 
build their own digital capability. 


Scott Guthrie, executive vice president, Cloud + Al, Microsoft 


Scott Hanselman 


The cloud is confusing. It's happening and it's scary, but it brings with 
it opportunity and power. One engineer can do the work of many with 
a Clear understanding of the cloud. | run three large websites in 
Azure and 15 small ones...alone. | have a CI/CD pipeline, reliable 
builds, automated tests in the cloud, automatic deployments, robust 
backups, and the result is scalable websites! 


This book is rooted in the real world of the cloud and builds on top of 
real code in the form of the eShopOnTheWeb sample. This sample 
is then modernized step by step and is moved into the cloud. 


There are enough tech books written in English. But this is a cloud 
book, an Azure book, a Brazilian book, written by Brazilians, for 
Brazilians. These engineers are your friends, your community 
leaders, and your software architects. 


As a member of the NEI and Azure team at Microsoft, | want to 
thank the authors for taking this journey, and thank YOU the reader 
for coming along! Let's build something great 


Scott Hanselman, partner program manager, Developer Division, 
Microsoft 


Quem somos nos? 


Alexandre Teoi é engenheiro de computação e atua com 
desenvolvimento de software há 30 anos. Nesse período, teve a 
oportunidade de trabalhar com várias linguagens (C, C++, CH), 
criando e depurando softwares nos mais diversos sistemas 
operacionais (MS-DOS, Windows, Unix e Linux). Nas horas livres, 
gosta de passar o tempo com a familia. 


https://www.|linkedin.com/in/ateoi/ 


Augusto Araujo atua como DevOps customer engineer no time de 
Apps & Infra Microsoft Brasil. Possui graduagao em Tecnologia em 
Processamento de Dados e trabalha com desenvolvimento e 
suporte ao DevOps ha 16 anos. Em seu tempo livre, gosta de 
praticar artes marciais (Jiu-Jitsu), assistir a séries e viajar para 
Minas Gerais para ver e passar um tempo com o Joaquim, seu filho. 


https://www.linkedin.com/in/augustodearaujo/ 


Beatriz Matsui é bacharel em Ciência da Computação e em Ciência 
e Tecnologia pela Universidade Federal do ABC (UFABC). Tem 
experiência nas áreas de Inteligência Artificial e aprendizado de 
máquina e atua com desenvolvimento de software, DevOps e 
codificação de testes. Atualmente, é consultora de Azure Cloud & Al 
na Microsoft e cursa o mestrado em Ciência da Computação na 
UFABC. Em seu tempo livre, gosta de ler, assistir a filmes e séries e 
aprender novos idiomas. 


https://www.linkedin.com/in/beatrizmatsui/ 


Christiano Donke trabalha com desenvolvimento desde os 12 anos 
de idade, e ha 10 profissionalmente. E especialista em 
desenvolvimento mobile, serviços cognitivos e chatbots. Trabalha na 
Microsoft há sete anos, atuando com suporte e ministrando 
treinamentos. Também atua como professor no curso de Inteligência 


Artificial do SENAC-SP. No tempo livre, gosta de ficar em familia, 
ver filmes e jogar um pouco. 


https://www.linkedin.com/in/cdonke/ 


Cleber Dantas é especialista em desenvolvimento de software com 
foco em computação em nuvem, arquitetura de soluções e 
troubleshooting. Tem 15 anos de experiência no mercado de TI, 
possui passagens por startups e empresas de grande porte. 


https://www.linkedin.com/in/cleberdantas/ 


Demetrio Costa atua como customer engineer na Microsoft. E 
formado em Processamento de Dados pela FATEC-SP e possui 
especialização em Engenharia de Software pela PUC-SP. Com 
quase 15 anos de experiência e 5 de Microsoft, atua com 
desenvolvimento e suporte de soluções diversas. Demetrio gosta de 
passar seu tempo livre com sua esposa Aline e seu filho Pedro, 
conhecendo lugares novos ou assistindo a filmes e séries. 


https://www.linkedin.com/in/demetrio-costa/ 


Eric Shimokawa sempre foi apaixonado por tecnologia e 
informatica. Aos 11 anos ja brincava de desenvolvimento em seu 
MSX e desde lá nunca mais abandonou o computador. Com mais de 
25 anos de experiência em TI, já atuou com infraestrutura, 
desenvolvimento, testes e gerenciamento de equipes. Apaixonado 
por agilidade e boas práticas, trabalhou por 8 anos como PFE/CE de 
Desenvolvimento e DevOps. Atualmente é Head de TI na Nova 
Futura Investimentos. 


https://www.linkedin.com/in/eric-shimokawa-23bbb86/ 


Fernando Henrique Inocéncio Borba Ferreira atua como software 
engineer em produtos dentro do Microsoft Azure. No passado, atuou 
como software engineer no Microsoft Windows e como premier field 
engineer em Modern Apps. Fernando possui bacharelado e 
mestrado em sistemas de informação. Atuando com 


desenvolvimento de software ha mais de dez anos, ele também foi 
Microsoft MVP em Data Platform Development e Visual C#. 
Fernando usa seu tempo livre com sua familia, livros, passeando ao 
ar livre e auxiliando pesquisas académicas. 


https://www.linkedin.com/in/ferhenrique/ 


lury Oliveira atua como customer engineer na Microsoft. Bacharel 
em Administração de Empresas e Ciência da Computação, trabalha 
com desenvolvimento e suporte ao desenvolvimento de software há 
quase 20 anos. Foi Microsoft Certified Trainer e ministra palestras 
em diversos eventos. Em seu tempo livre, gosta de ler, assistir a 
filmes, ir ao Parque do Ibirapuera com o pequeno João, seu primeiro 
filho. 


https://www.linkedin.com/in/iuryoliv/ 


James Jodai atua como customer engineer em CSU Apps & Infra. 
Possui bacharelado em Ciência da Computação e MBA em gestão 
estratégica e econômica de projetos e atua com suporte e 
desenvolvimento de software há mais de 20 anos. Em seu tempo 
livre, gosta de assistir a filmes com sua família e pescar. 


https://www.linkedin.com/in/jamesjodai/ 


José Otavio Quaglio atua como software engineer no time do 
M365. Anteriormente atuava como customer engineer no time de 
Apps & Infra. Possui bacharelado em Ciência da Computação e 
MBA em Gestão de Projetos. Trabalha com desenvolvimento de 
software e suporte há mais de 15 anos, em sua maior parte com 
tecnologias Microsoft. Em seu tempo livre costuma assistir a séries, 
jogar videogame, viajar e sair com os amigos e família. 


https://www.linkedin.com/in/joseotavioquaglio/ 


Leandro Prado (Pia) atua como customer engineer em Apps & Infra 
focado em DevOps. Bacharel em Sistemas de Informação pela 
PUC-PR, ao longo da carreira trabalhou como desenvolvedor em 


diversas linguagens (Delphi, PHP, Java, .NET) e atualmente ajuda 
clientes Microsoft Premier a adotar as melhores praticas em 
DevOps. Em seu tempo livre, costuma sujar a mao de graxa debaixo 
do seu carro de arrancada. 


https://www.linkedin.com/in/leandroprado/ 


Luís Henrique Demetrio possui bacharelado em Análise de 
Sistemas e pós-graduação em Engenharia de Software no ITA. 
Possui 20 anos de experiência na profissão. Trabalha como 
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Marcelo Tokunaga Nakamura é engenheiro do time Azure App 
Consult baseado em Sao Paulo e tem mais de 20 anos de 
experiéncia trabalhando com a Microsoft e parceiros desenvolvendo 
e arquitetando soluções. Desde 2010 trabalha com Azure focando 
em contêineres, dispositivos e microsserviços. Marcelo também é 
pai de três filhos e avô de um neto, músico e proprietário de um 
pequeno pet shop. 
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Apps & Infra. Formado em Analise de Sistema e MBA em 
Engenharia de Software. Atua com aplicações corporativas ha dez 
anos com foco em tecnologias Microsoft e projetos de integração. 
Em seu tempo livre, gosta de tocar clássicos do rock na 
guitarra/violão e estuda técnicas de fotografia. 
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Rafael Teixeira é formado em Engenharia da Computação, pós- 
graduado em Segurança da Informação pelo ITA e possui MBA em 
Gestão de Tecnologia pela FGV. É apaixonado por computadores e 
tecnologia desde a infância. Curioso em todas as áreas da 


computação, acabou focando sua carreira em desenvolvimento de 
software, análise avançada de performance e problemas produtivos 
de aplicações. Com mais de 12 anos de experiência e há 8 atuando 
como engenheiro (Customer Engineer) na Microsoft, ajuda clientes 
em suas jornadas de sucesso através da tecnologia. Além disso, 
participou do desenvolvimento de ferramentas e produtos da 
Microsoft, como o DebugDiag e .NET Performance Tuning e 
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assistir a algo interessante na televisão. 


https://www.linkedin.com/in/vafzamora/ 


Introdução 


Sejam bem-vindos ao mundo da computação, onde aplicações 
podem ser desenvolvidas em um curto espaço de tempo e 
hospedadas em ambientes prontos e capazes de atender qualquer 
volume de usuários simultâneos ou de demanda de negócio, seja 
ele sazonal ou diário. E sim, estamos falando da computação em 
nuvem, no mundo Microsoft, o Microsoft Azure. 


Logicamente, essa é uma afirmação que conta com inúmeras 
variáveis para ser verdadeira. Mas felizmente a maioria delas está 
cada vez mais sob responsabilidade de quem constrói as 
aplicações, sejam eles arquitetos de desenvolvimento, arquitetos de 
infraestrutura ou desenvolvedores. No atual momento em que 
vivemos, a maioria dos serviços utilizados pelas aplicações, como 
banco de dados, caches, notificações, mensagerias, monitorações e 
outros, já foi pensada, desenhada e desenvolvida na nuvem para ter 
alta disponibilidade, escalabilidade e, dessa forma, atender 
altíssimos volumes de transações simultâneas, e tudo dependendo 
apenas das escolhas corretas dos serviços de nuvem, seu tamanho, 
região e suas configurações. 


Não estamos afirmando que toda a responsabilidade de fazer uma 
aplicação cumprir o seu papel com excelência seja unicamente do 
time que a produziu, mas com certeza conseguimos afirmar que 
cada vez mais o poder para isso acontecer está nas mãos dos 
arquitetos e desenvolvedores, pois toda infraestrutura necessária (e 
serviços dependentes) para rodar nossas aplicações está pronta, 
disponível e cada dia mais robusta e madura. Sabemos também que 
o sucesso de uma aplicação não está apoiado unicamente no seu 
processo de desenvolvimento inicial, mas sim em um ciclo de 
desenvolvimento e entrega contínua, e aqui entra a importância da 
cultura e prática DevOps. 


Porém, para que possamos extrair todo esse potencial mencionado 
da computação em nuvem para nossas aplicações, precisamos 


conhecer os serviços disponíveis na nuvem, suas características de 
uso e corretas aplicabilidades. Somente assim tomaremos as 
decisões corretas para obter os principais benefícios da computação 
em nuvem, que estão atreladas a produtividade e agilidade no 
desenvolvimento (time to market), disponibilidade, performance e 
eficiência operacional (redução de custos). 


Além de conhecer os serviços disponíveis e suas características a 
fim de fazer as escolhas corretas dadas as necessidades de sua 
aplicação, também precisamos entender os novos padrões de 
arquitetura, desenvolvimento e metodologias para obter os 
benefícios da computação em nuvem. Por exemplo, para termos 
uma aplicação com alta disponibilidade, não podemos contar 
somente com as escolhas corretas dos serviços de nuvem, 
precisamos também definir uma arquitetura e produzir código capaz 
de se recuperar de erros em tempo de execução (resiliente) e 
escalar com base na demanda, sem perder performance. 


Agora imagine a situação de aplicações que recebem grandes 
variações no volume de acessos e processamento, com picos 
baseados em sazonalidades e datas especiais. Se elas não forem 
arquitetadas e construídas pensando nos pontos mencionados, 
provavelmente não conseguirão tirar proveito da computação em 
nuvem e sua performance não será satisfatória. 


O objetivo aqui não é trazer uma visão de dificuldade ou 
complexidade para o desenvolvimento de aplicações para nuvem, 
muito pelo contrário, pois ela realmente traz muita facilidade, 
agilidade e um potencial quase sem limites para nossas 
necessidades atuais. O objetivo principal até aqui é entendermos 
que, quanto mais essas aplicações estiverem adequadas para 
nuvem, melhor poderão explorar os benefícios deste novo mundo, 
citados anteriormente. Dessa forma, uma aplicação que foi 
desenhada para nuvem desde o início de seu desenvolvimento com 
certeza terá vantagem em obter esses benefícios. 


Sabemos que esse não é um cenário único, principalmente falando 
do mundo corporativo, que possuía aplicações projetadas e 
desenvolvidas em uma época em que nem se imaginava a 
computação em nuvem. Agora, essas aplicações podem ser 
migradas para nuvem e obter os mesmos benefícios através de um 
processo de modernização. É exatamente este cenário que 
exploraremos em detalhes neste livro. Passaremos por todas as 
etapas, processos, conceitos e práticas para levar uma aplicação 
não projetada para nuvem, obtendo o máximo da computação em 
nuvem. 


Antes de iniciarmos nossa jornada na modernização de aplicação, 
falaremos um pouco sobre alguns conceitos essenciais do Microsoft 
Azure e também do Microsoft Azure Well-Architected Framework, 
framework de arquitetura de soluções para nuvem. Esses conceitos 
serão a base para nossa jornada e todas as ações tomadas durante 
a modernização. 


Como este livro está organizado? 


O livro está organizado para você ter uma sequência cronológica 
para migrar sua aplicação para a nuvem. Começamos no Capítulo 
1 - Conceitos iniciais falando dos conceitos básicos, modelos de 
implantação e sobre o framework Azure Well-Architected. 


No Capítulo 2 - Lift & Shift, apresentamos a arquitetura da 
aplicação que vamos utilizar no livro e abordamos a estratégia Lift & 
Shift de migração para o Microsoft Azure com o mínimo de 
alterações. 


No Capítulo 3 - Provisionamento da infraestrutura, criaremos 
todo o ambiente necessário para a aplicação onde ela possa ser 
facilmente escalada e, no Capítulo 4 - Publicação da aplicação, 


vamos adapta-la para que ela seja executada em um ambiente 
escalável e fazer a primeira publicação da aplicação. 


No Capítulo 5 - Automação da publicação, criaremos um script 
para ajudar em todos os processos de publicação. 


No Capítulo 6 - Gerenciamento de código-fonte, começamos a 
adicionar algumas práticas básicas para o time de desenvolvimento, 
como gerenciamento de código, estratégias de branch e merge 
usando o GitHub e a adotar algumas práticas de DevOps, como 
Integração Contínua (Cl) e Entrega Contínua (Continuous Delivery). 
Vamos usar GitHub Actions para automatizar todo o processo de 
Build e Release visto no capítulo anterior. Com a aplicação rodando 
no Microsoft Azure, adicionaremos algumas melhorias na aplicação. 


Dentro do Capítulo 7 - Monitoramento da solução, vamos 
configurar o Application Insights para monitorar a aplicação, 
acompanhar algumas métricas e começar a conhecer os usuários 
da aplicação, criando um processo de feedback contínuo. 


No Capítulo 8 - Testes & QA, vamos melhorar o processo de 
desenvolvimento com a adoção de testes unitários, testes 
integrados, testes de interface etc., aumentando a qualidade da 
nossa aplicação. 


Para realizar a execução dos testes de maneira automatizada, no 
Capítulo 09 - Automação em ambientes de testes, descrevemos 
como criar um ambiente isolado para rodar os testes e também 
integrar a execução do testes unitários como parte do processo de 
Cl. 


A partir do Capitulo 10 - Desacoplamento iniciamos uma jornada 
de melhorias na aplicação. Para que a aplicação possa evoluir, é 
necessário que ela possua características de flexibilidade e 
manutenibilidade que podemos obter através de baixo acoplamento 
entre as suas partes utilizando interfaces e injeção de 
dependências. 


No Capitulo 11 - Microsserviços, vamos abordar como podemos 
evoluir nossa aplicação monolítica para que ela possa atender uma 
maior demanda de usuários adotando uma arquitetura de 
microsserviços. 


No Capítulo 12 - Introdução ao contêiner, iniciamos a criação de 
imagens Docker. Vamos enviá-las para um Container Registry e 
reconfigurar nosso processo de Cl para automatizar tudo isso. 
Depois, no Capítulo 13 - Orquestração de contêineres, veremos 
como podemos migrar a aplicação para rodar em um ambiente 
Docker e sendo orquestrado pelo Kubernetes. 


No Capítulo 14 - Identidade, vamos falar sobre os protocolos 
OAuth 2.0 e OpenID Connect e algumas formas de manter a 
aplicação mais segura utilizando serviços de gestão de identidade e 
proteção como o Azure B2C. 


Por fim, no Capítulo 15 - Resumo falamos sobre os benefícios que 
toda essa jornada de adoção à nuvem trouxe para a aplicação e 
outros serviços do Azure que podemos utilizar. 


CAPITULO 1 
Conceitos iniciais 


Escrito por Rafael Teixeira e Leandro Prado. 


1.1 O que é o Microsoft Azure? 


O Azure é uma plataforma de nuvem da Microsoft, na qual podemos 
hospedar aplicações e utilizar diversos serviços de tecnologia de 
forma prática e eficiente. O Azure disponibiliza inúmeros serviços, 
como Al + Machine Learning, Container, base de dados, redes, 
discos, aplicações Web etc. Você pode ver todos os serviços 
disponibilizados pelo Azure através deste link: 
https://azure.microsoft.com/en-in/services/. 


Atualmente o Azure possui data centers distribuidos pelo mundo 
todo, divididos em 64 regides conforme a figura a seguir. Cada 
regiao possui mais de um data center para garantir a alta 
disponibilidade caso ocorra algum desastre. No momento em que 
este livro esta sendo escrito, o AZure possui data centers em duas 
regiões no Brasil (Brazil South e Brazil Southeast) para serviços que 
necessitam de alta disponibilidade. 








Figura 1.1: Regiões do Azure. 


Para mais detalhes das regiões do Azure 
https://azure.microsoft.com/en-us/global-infrastructure/geographies/. 


Vantagens de computação em nuvem 


e Pay-as-you-go: os clientes não precisam comprar hardware e 
software para recursos de nuvem. Não há despesas de capital 
para usar um recurso na nuvem, os clientes simplesmente 
pagam pelo tempo que usaram aquele recurso. 

e Acesso global: os recursos da nuvem estão disponíveis 
globalmente através da internet. Os clientes podem acessar 
seus recursos sob demanda de qualquer lugar. 

e Recursos ilimitados: a escala da nuvem é ilimitada; os 
clientes podem provisionar quantos recursos eles quiserem, 
sem quaisquer restrições. Isso é também conhecido como 
escalabilidade ilimitada. (Para evitar um desperdício de 
consumo de recursos excessivos, cada subscrição do Azure 
possui limites, que podem ser alterados através de chamados 
criados para o suporte do Azure). 

e Serviços gerenciados: o provedor de nuvem fornece vários 
serviços que são geridos por eles para os clientes. Isso permite 


uma diminuição no gerenciamento técnico desses serviços, 
aumentando a facilidade de administração por parte dos 
clientes. 


1.2 Modelos de implantação 


A adoção da nuvem pode ser realizada através de três tipos 
diferentes para a implantação de sua solução. 


Infraestrutura como serviço (Infrastructure as a service — laasS, 
em inglês) 


laaS é o tipo de implantação que permite que os clientes 
provisionem sua infraestrutura no Azure, ou seja, nesse modelo é 
possível criar máquinas virtuais, redes, discos etc. sem precisar de 
um data center. Uma das vantagens do laaS é aumentar seu poder 
de processamento de maneira fácil. Outra vantagem em utilizar laaS 
é não ter o custo de compra e manutenção do hardware, todo esse 
trabalho é gerenciado e garantido pelo provedor de nuvem. Por 
outro lado, o cliente tem total acesso à infraestrutura e consegue 
gerenciá-la/provisioná-la conforme sua necessidade. 


Plataforma como serviço (Platform as a service — PaaS, em 
inglês) 


O PaaS abstrai a camada de infraestrutura para os clientes. Esse 
modelo é mais fácil de provisionar e manter, pois o cliente não 
necessita gerenciar as máquinas e nem o sistema operacional, ou 
seja, a Microsoft cuida de toda infraestrutura e o cliente só vai se 
preocupar com o seu negócio e com a sua aplicação. Alguns dos 
serviços PaaS disponibilizados no Azure são Kubernetes, WebApp, 
Databases etc. 


Software como serviço (Software as a service - SaaS, em 
inglés) 


SaaS é o nivel mais alto de abstração no qual o provedor de nuvem 
é responsável por manter toda a infraestrutura e toda a manutenção 
da aplicação, o cliente final só tem a preocupação de 
utilizar/gerenciar a aplicação. Alguns exemplos de SaasS são: 
ferramentas do Office 365, Dynamics etc. 


A figura exemplifica a comparação entre esses três modelos de 
implantação. 
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Figura 1.2: Comparação entre laaS x PaaS x SaaS. 


1.3 Microsoft Azure Well-Architected 


A nuvem mudou a maneira como as organizações resolvem seus 
desafios de negócios e como as aplicações são projetadas. Por 
isso, quando estamos desenvolvendo uma solução para a nuvem, é 
preciso garantir que ela seja projetada de forma escalonavel, 
resiliente, eficiente e segura. Estes requisitos não funcionais são 


bem importantes para seu sucesso, por isso devemos sempre nos 
questionar: como você pode passar para seus clientes a confiança 
de que os dados deles estão seguros? Como a arquitetura que você 
desenhou se comportará durante um pico de acesso? Como sua 
aplicação se comportará se uma falha ocorrer em algum 
componente crítico? Você está usando os recursos da maneira mais 
eficiente possível? Para ajudar você a responder a essas e a muitos 
outros questionamentos, foi criado o framework Microsoft Azure 
Well-Architected. 


O framework Azure Well-Architected é um conjunto de princípios 
que podem ser utilizados para melhorar a qualidade da arquitetura e 
dos recursos que você está criando ou migrando para nuvem. Ele 
consiste em cinco pilares: 


e Otimização de custos; 

e Excelência operacional; 
Eficiência de desempenho; 
e Confiabilidade; 

e Segurança. 


Esses conceitos não podem ser considerados balas de prata, mas 
levar em conta esses princípios vai ajudar a construir uma base 
confiável, segura e flexível para sua solução. 


Mesmo após a implementação inicial de soluções considerando 
esses princípios, é recomendado que eles sejam revisitados de 
forma rotineira para garantir que melhorias e ajustes realizados na 
solução se mantenham dentro das boas práticas e recomendações. 
Dessa forma, a solução continua extraindo o potencial máximo da 
computação em nuvem. 


Otimização de custos 


Os princípios de otimização de custos englobam uma série de 
considerações importantes que podem ajudar a desenhar uma 


solução eficiente, que elimine perdas e forneça visibilidade de onde 
seu dinheiro está sendo gasto dentre os recursos da nuvem. 


Mantenha-se dentro das restrições de custo: cada escolha de 
arquitetura tem implicações de custo. Antes de escolher um padrão 
de arquitetura, serviço do Azure ou um modelo de preço para o 
serviço, considere as restrições de orçamento definidas pela 
empresa. Como parte do projeto, identifique limites aceitáveis em 
escala, redundância e desempenho em relação ao custo. Depois de 
estimar o custo inicial, defina orçamentos e alertas em diferentes 
escopos para medir o custo mensal e anual. 


NOTA 


O Azure possui uma calculadora que nos permite estimar o 
custo de cada um dos recursos que vamos utilizar. Ela pode ser 
acessada por meio do link a seguir: 


https://azure.microsoft.com/pt-br/pricing/calculator/ 





Busque custos escalonaveis: um benefício importante da nuvem é 
a capacidade de escalar dinamicamente. Considere as métricas de 
uso e desempenho para determinar o número de instâncias de que 
sua aplicação necessita. Escolha instâncias menores para uma 
carga de trabalho altamente variável e expanda para obter o nível 
de desempenho necessário. Você pode economizar custos por meio 
do dimensionamento automático. 


Pague pelo consumo: adote um modelo de locação em vez de 
adquirir toda uma infraestrutura. O Azure oferece muitos serviços 
SaaS e PaaS que simplificam a arquitetura do seu ambiente. Todo o 
custo de hardware, software, desenvolvimento, operações, 
segurança e espaço do data center está incluso no modelo de 
preços do Azure. Além disso, opte por pagar conforme o uso (pay- 
as-you-go) em vez de preço fixo. Dessa forma, você é cobrado 
apenas pelo tempo que o recurso foi utilizado. 


Serviços certos, com o tamanho certo: um serviço inadequado, 
configurado de maneira errada ou mal dimensionado, pode afetar os 
custos. Por exemplo, ao construir um serviço multirregional, quando 
não é exigida alta disponibilidade ou redundância geográfica, isso 
aumentará o custo sem qualquer justificativa comercial razoável. 
Certifique-se de que todos os serviços sejam dimensionados 
adequadamente para atender à demanda de capacidade e entregar 
o desempenho esperado. 


Monitore e otimize: trate o monitoramento e a otimização de custos 
como um processo em vez de uma atividade pontual. Conduza 
revisões de custo regulares, meça e preveja as necessidades de 
capacidade para que você possa provisionar serviços 
dinamicamente e escalar conforme a demanda. 


Excelência operacional 


Este pilar cobre os processos operacionais que mantêm uma 
aplicação rodando em produção. As implantações devem ser 
confiáveis e previsíveis, devem ser automatizadas para reduzir a 
chance de erro humano e devem ser um processo rápido e rotineiro 
para não retardar a disponibilização de novas funcionalidades ou 
correções de bugs. Também é importante ser capaz de reverter 
(rollback) ou avançar rapidamente se uma atualização apresentar 
problemas. Para alcançar uma execelência operacional é preciso 
executar algumas práticas: 


Otimize os processos de Build e Release: faça o provisionamento 
da sua infraestrutura como código, automatize seu processo de 
build e release (CI/CD), execute testes automatizados em toda a 
alteração. Essa abordagem garante que a criação e o 
gerenciamento de ambientes em todo o ciclo de vida de 
desenvolvimento de software sejam consistentes, repetíveis e 
possibilitem a detecção precoce de problemas. 


Monitore todo o sistema e entenda a integridade operacional: 
adote sistemas e processos para monitorar os processos de Build e 
Release, a integridade da infraestrutura e da sua aplicação. A 
telemetria é fundamental para compreender a integridade dos 
serviços e se eles estão atendendo às metas de negócios. 


Ensaie a recuperação e pratique o fracasso: execute exercícios 
de disaster and recovery (DR) em uma cadência regular e use 
práticas de engenharia para identificar e corrigir os pontos fracos na 
confiabilidade da aplicação. O ensaio regular de DR validará a 
eficácia dos processos de recuperação e garantirá que as equipes 
estejam familiarizadas com suas responsabilidades. 


Abrace a melhoria operacional: avalie e refine continuamente os 
procedimentos e tarefas operacionais enquanto se esforça para 
reduzir a complexidade e a ambiguidade. Essa abordagem permite 
que uma organização desenvolva processos ao longo do tempo, 
otimizando ineficiências e aprendendo com as falhas. 


Use arquitetura fracamente acoplada: permita que as equipes 
testem, implantem e atualizem de forma independente seus 
sistemas sob demanda, sem depender de outras equipes para 
suporte, serviços, recursos ou aprovações. 


Gestão de incidentes: quando ocorrerem incidentes, tenha planos 
e soluções bem elaborados para gerenciamento de incidentes, 
comunicação de incidentes e ciclos de feedback. Aproveite as lições 
aprendidas com cada incidente e construa elementos de telemetria 
e monitoramento para prevenir ocorrências futuras. 


Eficiência de desempenho 


Eficiência de desempenho é a capacidade da sua aplicação ou 
serviço ser escalonado para atender às demandas dos usuários de 
maneira eficiente. 


Escalabilidade é a capacidade de um sistema de lidar com o 
aumento da carga. O Azure possui alguns serviços de Autoscale 


que podem ser escalonados automaticamente para atender a 
demanda. Eles serao dimensionados para garantir a capacidade 
durante os picos de carga de trabalho e o dimensionamento 
retornará ao normal automaticamente quando o pico cair. 


Na nuvem, a capacidade de aproveitar as vantagens da 
escalabilidade depende de sua infraestrutura e serviços. Algumas 
plataformas, como o Kubernetes, foram criadas com o 
dimensionamento em mente. As máquinas virtuais, por outro lado, 
podem não escalar tão facilmente, embora as operações de 
escalonamento sejam possíveis. A seguir listamos algumas 
orientações para melhorar a performance e eficiência: 


Torne-se orientado a dados: abrace uma cultura orientada a dados 
para fornecer insights oportunos para todos em sua organização em 
todos os seus dados. Para aproveitar essa cultura, obtenha o 
melhor desempenho de sua solução analítica em todos os seus 
dados, certifique-se de que os dados têm a segurança e a 
privacidade necessárias para seu ambiente de negócios, e tenha 
ferramentas que permitam a todos em sua organização obter 
insights de seus dados. 


Evite antipatterns: um antipattern de desempenho é uma prática 
comum que provavelmente causará problemas de escalabilidade 
quando um aplicativo estiver sob pressão. Por exemplo, você pode 
ter um aplicativo que se comporte conforme o esperado durante o 
teste de desempenho. No entanto, quando ele é lançado para 
produção e começa a lidar com cargas de trabalho ativas, o 
desempenho diminui. Podem surgir problemas de escalabilidade, 
como rejeição de solicitações do usuário, paralisação ou lançamento 
de exceções. 


NOTA 


Para saber como identificar e corrigir esses antipadrões, 


consulte o link: https://docs.microsoft.com/en- 
us/azure/architecture/antipatterns/ 





Execute o teste de carga para definir limites: o teste de carga 
ajuda a garantir que seus aplicativos possam escalar e não caiam 
durante o pico de tráfego. Faça o teste de carga de cada aplicativo 
para entender seu desempenho em várias escalas. 


Entenda a cobrança de recursos medidos: seus requisitos de 
negócios determinarão as compensações entre custo e nível de 
eficiência de desempenho. O Azure não cobra diretamente com 
base no custo do recurso. As cobranças por um recurso, como uma 
máquina virtual, são calculadas usando um ou mais medidores. 
Medidores são usados para rastrear o uso de um recurso ao longo 
do tempo e para calcular a conta. 


Monitore e otimize: a falta de monitoramento de novos serviços e a 
integridade das cargas de trabalho atuais são os principais 
inibidores da qualidade dos serviços. A estratégia geral de 
monitoramento deve levar em consideração não apenas a 
escalabilidade, mas também a resiliência (infraestrutura, aplicativos 
e serviços dependentes) e o desempenho do aplicativo. Para fins de 
escalabilidade, olhar para as métricas permitiria provisionar recursos 
dinamicamente e escalar com a demanda. 


Confiabilidade 


Construir uma aplicação confiável na nuvem é diferente do 
desenvolvimento tradicional. Embora historicamente você possa ter 
adquirido níveis de hardware redundante de ponta para minimizar a 
chance de uma plataforma de aplicação falhar, na nuvem, 
reconhecemos de antemão que as falhas acontecerão. Em vez de 


tentar evitar todas as falhas, o objetivo é minimizar os efeitos de um 
Único componente com falha. 


Abaixo listamos alguns princípios que devem ser seguidos para 
construir uma aplicação com alta confiabilidade. 


Construa aplicações resistentes a falhas: Defina metas de 
confiabilidade, projete uma arquitetura que seja resiliente e que seja 
facilmente recuperada de falhas. Planeje recuperações em caso 
de falhas: A recuperação de desastres é o processo de restauração 
da aplicação após uma falha catastrófica. Pode ser aceitável que 
algumas aplicações fiquem indisponíveis ou parcialmente 
disponíveis com funcionalidade reduzida por um período de tempo, 
enquanto outras aplicações não aceitam nenhum tipo de falha ou 
indisponibilidade. Construa aplicações que se recuperem de 
erros - Os aplicativos resilientes devem ser capazes de se 
recuperar automaticamente de erros usando padrões de arquitetura 
em nuvem. Certifique-se de que a rede e a conectividade 
atendam aos requisitos de confiabilidade: Identificar e mitigar 
possíveis gargalos ou pontos de falha da rede oferece suporte a 
uma base confiável e escalonável sobre a qual os componentes das 
aplicações podem se comunicar. Permita confiabilidade na 
escalabilidade e desempenho: As aplicações devem ser capazes 
de escalar automaticamente em resposta à mudança de carga para 
manter a disponibilidade e atender aos requisitos de desempenho 
definidos pelo time. Defina, automatize e teste processos 
operacionais: Os processos operacionais para implantação da 
aplicação, como novas versões e rollback em caso de falhas, devem 
ser definidos, suficientemente automatizados e testados para ajudar 
a garantir o alinhamento com as metas de confiabilidade. Monitore 
e meça a integridade: Monitorar e medir a disponibilidade da 
aplicação é vital para qualificar a integridade do ambiente e o 
progresso em direção a metas de confiabilidade definidas. 


Segurança 


A segurança é um dos aspectos mais importantes de qualquer 
arquitetura. É ela que fornece garantias de confidencialidade, 
integridade e disponibilidade contra ataques deliberados e abuso de 
seus valiosos dados e sistemas. A perda dessas garantias pode 
impactar negativamente suas operações de negócios e receita, bem 
como a reputação da sua organização no mercado. 


A seguir descrevemos alguns princípios para segurança: 


Alinhar as prioridades de segurança com a missão: os recursos 
de segurança são quase sempre limitados, portanto priorize os 
esforços e as garantias alinhando a estratégia de segurança e os 
controles técnicos com os negócios usando a classificação de dados 
e sistemas. Os recursos de segurança devem ser concentrados 
primeiro em pessoas e ativos (sistemas, dados, contas etc.) com 
valor comercial intrínseco e aqueles com privilégios administrativos 
sobre ativos críticos para os negócios. 


Crie uma estratégia abrangente: uma estratégia de segurança 
deve considerar os investimentos em cultura, processos e controles 
de segurança em todos os componentes do sistema. Ela também 
deve considerar a segurança para o ciclo de vida completo dos 
componentes, incluindo a cadeia de fornecedores de software, 
hardware e serviços. 


Simplicidade: a complexidade de sistemas leva a uma maior 
confusão humana, erros, falhas de automação e dificuldade de 
recuperação de um problema. Favoreça arquiteturas e 
implementações simples e consistentes. 


Design para invasores: o design e a priorização de segurança 
devem se concentrar na maneira como os invasores veem seu 
ambiente, o que geralmente não é a maneira como as equipes de Tl 
e de aplicação o veem. Defina equipes para realizarem testes de 
penetração para simular ataques. Continuamente meça e reduza 
uma possível invasão por meio da qual invasores visam explorar 
recursos dentro do seu ambiente. 


Aproveitar controles nativos: Prefira controles de segurança 
nativos incorporados aos serviços de nuvem a controles externos de 
terceiros. Os controles de segurança nativos são mantidos e têm 
suporte do provedor de serviços, eliminando ou reduzindo o esforço 
necessário para integrar as ferramentas de segurança externa e 
atualizar essas integrações ao longo do tempo. 


Usar identidade como controle de acesso primário: o acesso a 
recursos em arquiteturas de nuvem é basicamente regido por 
autenticação baseada em identidade e autorização para controles 
de acesso. Sua estratégia de controle de conta deve depender de 
sistemas de identidade para controlar o acesso em vez de depender 
de controles de rede ou uso direto de chaves de criptografia. 


Responsabilidade: defina com clareza os responsáveis 
(ownership) dos recursos e suas responsabilidades de segurança e 
garanta que todas as ações sejam rastreáveis. Você também deve 
garantir que todos os recursos tenham recebido o privilégio mínimo 
necessário de acesso. 


Adotar automação: a automação de tarefas diminui a chance de 
erro humano que pode criar riscos, de modo que as práticas 
recomendadas de operações de TI e de segurança devem ser 
automatizadas tanto quanto possível para reduzir erros humanos 
(ao mesmo tempo em que garantem que os humanos capacitados 
rejam e auditem a automação). 


Foco na proteção de informações: a propriedade intelectual é 
frequentemente um dos maiores repositórios de valor organizacional 
e esses dados devem ser protegidos em qualquer lugar, incluindo 
serviços de nuvem, dispositivos móveis, estações de trabalho ou 
plataformas de colaboração (sem impedir a colaboração que permite 
a criação de valor comercial). Sua estratégia de segurança deve ser 
criada em relação à classificação de informações e ativos para 
habilitar a priorização de segurança. Deve aproveitar a tecnologia de 
criptografia e o controle de acesso forte, atendendo às 


necessidades comerciais, como produtividade, usabilidade e 
flexibilidade. 


Supor zero confiança: ao avaliar solicitações de acesso, todos os 
usuários, dispositivos e aplicativos solicitantes devem ser 
considerados não confiáveis até que sua integridade possa ser 
validada suficientemente. As solicitações de acesso devem ser 
concedidas condicionalmente com base no nível de confiança dos 
solicitantes e na sensibilidade do recurso de destino. 


Treine e incentive segurança: os seres humanos que estão 
projetando e operando as cargas de trabalho de nuvem fazem parte 
do sistema inteiro. É essencial garantir que essas pessoas sejam 
instruídas, informadas e incentivadas a dar suporte às metas de 
garantia de segurança do sistema. Isso é particularmente importante 
para pessoas com contas que receberam privilégios administrativos 
amplos. 


Agora que os conceitos básicos sobre computação em nuvem foram 
esclarecidos, podemos iniciar a jornada de migração da nossa 
aplicação para o Azure. Essa jornada começa com o Lift & Shift, que 
veremos no próximo capítulo. 


Todos os artefatos produzidos no decorrer da criação deste livro 


estão disponibilizados em nosso repositório oficial no endereço: 
https://github.com/CEProjectFalcon 





CAPITULO 2 
Lift & Shift 


Escrito por Alexandre Teoi e Luis Henrique Demetrio. 


CENARIO 


A empresa eShopOnWeb começou a ter problemas operacionais 
e de estabilidade na sua principal aplicação de comércio 
eletrônico, principalmente nas datas comemorativas. Existe uma 
grande dificuldade para provisionar equipamentos necessários 


para suportar a carga desses períodos e a aplicação não 
consegue atender os clientes de forma satisfatória, 
apresentando lentidão e erros. 


Fora das datas comemorativas, o volume de acesso diminui 
significativamente e os equipamentos ficam ociosos, havendo 
um desperdício de recursos computacionais. 





Esse é um ótimo exemplo de empresa que pode se beneficiar do 
ambiente em nuvem, pois ele oferece serviços que permitem 
facilmente escalar a infraestrutura nos períodos de maior demanda 
e reduzi-la quando a carga diminuir. E, como os ambientes em 
nuvem só cobram por serviços utilizados, não há desperdício de 
recursos computacionais, o que ocorre frequentemente nos centros 
de processamento de dados locais. 


Neste livro, acompanharemos o processo de adoção do Microsoft 
Azure por essa empresa mostrando gradualmente a migração de 
uma aplicação que não foi projetada para ser hospedada na nuvem. 


2.1 Aplicação utilizada 


Para fins didáticos, neste livro, adotamos a aplicação eShopOnWeb, 
um exemplo de uma loja on-line desenvolvida em ASPNET Core 
3.1. 
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Figura 2.1: Aplicação eShopOnWeb. 


O ASP.NET Core é um framework multiplataforma de código 
aberto para a criação de aplicações Web. Faz parte do NEI 
Core, que é a plataforma de desenvolvimento, também de 
código aberto, da Microsoft. 


Mais detalhes em: 


https://docs.microsoft.com/aspnet/core/introduction-to-aspnet- 
core 





A aplicação é open-source e esta disponível no seguinte repositório 
do GitHub: 


https://github.com/dotnet-architecture/eShopOnWeb 


Essa aplicação é a mesma utilizada como base das explicações do 
livro Architecting Modern Web Applications with ASPNET Core and 
Microsoft Azure, de Steve "ardalis" Smith, disponível para download 
gratuito no endereço: 


https://docs.microsoft.com/dotnet/architecture/modern-web-apps- 
azure/ 


Visando melhorar a utilização da aplicação para o cenário deste 
livro, realizaremos um fork do repositório original e adequaremos 
para o nosso cenário proposto. Apenas para adiantar, conforme a 
documentação oficial do GitHub, o fork é uma cópia de um 
repositório no qual podemos realizar mudanças sem afetar o projeto 
original, ao mesmo tempo em que mantém a rastreabilidade de 
onde o repositório foi obtido. No capítulo Gerenciamento de 
código-fonte será descrito o procedimento para a criação do 
repositório com a ferramenta cit assim como os conceitos 
relacionados. 


Obtenção da aplicação 
Utilize o seguinte endereço para baixar o código-fonte da aplicação: 


https://github.com/dotnet- 
architecture/eShopOnWeb/archive/master.zip 


Descompacte o conteúdo do arquivo no diretório c:\Repos\eShopOnweb . 
Segue o conteúdo da aplicação após descompactarmos o arquivo: 


> ThisPC > OSDisk(C:) > Repos > eShopOnWeb 


[] Name l Date modified Type Size 
src 21/01/2021 16:26 File folder 
DO eShopOnWeb.sln 06/10/2020 21:03 Visual Studio Solu... 5 KB 
| | LICENSE 06/10/2020 21:03 File 2 KB 
+ README.md 06/10/2020 21:03 Markdown Source... 7 KB 


Figura 2.2: Conteúdo do repositório local. 
Explorando a aplicação 


Ao abrir a solução eShopOnWeb.sin no Visual Studio é possível 
verificar que ela é composta pelos projetos ApplicationCore, 
BlazorAdmin, BlazorShared, Infrastructure, PublicAPI e Web. 
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Figura 2.3: Projetos da aplicação eShopOnWeb. 


O módulo de administração do site é implementado pelo projeto 
BlazorAdmin que está desenvolvido em Blazor WebAssembly e, 
consequentemente, é executado no navegador. Para acessar o 


modulo administrativo é necessário realizar o login através de uma 
conta administrativa. Após entrar com esse usuário, aparecerá a 
opção de acessar esse módulo no menu do usuário. 


O ASPNET Core Blazor é um framework para a construção de 
interfaces de usuário interativas para navegadores modernos 
utilizando a linguagem C# em vez de JavaScript. A 


documentação oficial do Blazor está disponível no endereço: 


https://docs.microsoft.com/aspnet/core/blazor/ 
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Figura 2.4: Menu do sistema. 
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Figura 2.5: Módulo de administração. 


O BlazorAdmin, por sua vez, depende do projeto PublicApi para 
realizar a comunicação com o servidor via Web APIs. A solução 
concentra todas as APIs em um unico projeto, o que pode dificultar 
a escalabilidade de recursos individualmente e a manutenção. 


Swagger UI 
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Swagger ENS RAR My API v1 E 
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Figura 2.6: Interface das APIs. 


Para executar a aplicação no Visual Studio, é necessário configurar 
a execução de múltiplos projetos através das propriedades da 
solução. Para isso, no menu Debug, execute o comando set startup 
Projects... , Vá para a opção Multiple startup projects e selecione 
somente os projetos PublicAPI e Web. 


(O Current selection 


(O Single startup project 


Web 





Project Action 

| ApplicationCore None o 
BlazorAdmin None ba 
BlazorShared None bo 
Infrastructure None Z 
PublicApi bra Start ba 
Web == Start ” 








Figura 2.7: Execução de múltiplos projetos. 


Execute a aplicação e verifique se ela está funcionando 
corretamente na estação de desenvolvimento. Para isso, no menu 
Debug, selecione o comando start Debugging . 


2.2 Estratégia de migração com Azure 


No cenário inicial, consideramos que a aplicação eShopOnWeb está 
hospedada localmente (on-premises) em servidores Linux com o 
NGINX atuando como proxy reverso. O NGINX (http://nginx.com) é 
um servidor Web de código aberto que também pode atuar como 
proxy reverso. 


Iniciaremos a jornada para a nuvem através da abordagem Lift & 
Shift (levantar e mover, em portugués) que tem como objetivo 
migrar uma aplicação com uma quantidade minima de alterações, 
seja de código ou infraestrutura. É por isso que essa abordagem 
utiliza a modalidade de infraestrutura como serviço (/aaS), pois ela 
permite replicar o ambiente de hospedagem da aplicação local na 
nuvem. 


Como a premissa do Lift & Shift é minimizar alterações, essa 
abordagem é muito utilizada como o primeiro passo de migração de 
uma aplicação para a nuvem. Mesmo assim, com a migração já é 
possível ter os benefícios da nuvem, com destaque para a agilidade 
na criação e manutenção da infraestrutura, automação do processo 
de escalar o ambiente e minimizar a quantidade de equipamentos 
ociosos. 


Para a migração da aplicação eShopOnWeb, utilizaremos a 
seguinte arquitetura. Os detalhes de cada componente dessa 
arquitetura serão descritos adiante nos próximos capítulos. 
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Figura 2.8: Arquitetura proposta. 
Criagao de uma conta no Azure 


Para reproduzir os cenarios apresentados neste livro, caso nao 
possua uma conta no Azure, é possível obter uma conta gratuita 
para criar máquinas virtuais, armazenamento e bancos de dados 
através do site https://azure.microsoft.com/free. 


Uma vez que temos uma conta no Microsoft Azure, o próximo passo 
é instalar a ferramenta de gerenciamento da sua assinatura do 
Azure. 


Instalação da ferramenta Azure CLI 


No próximo capítulo, provisionaremos o ambiente na nuvem através 
da ferramenta Azure CLI (Command Line Interface). Apesar de o 
portal do Microsoft Azure (http://portal.azure.com) permitir atingir o 


mesmo objetivo de forma visual, na pratica as empresas optam por 
utilizar essa ferramenta para permitir a replicação e automação 
desse processo. 


Existem diferentes maneiras de instalar o Azure CLI, inclusive para 
diferentes sistemas operacionais, como Linux e macOS. Nesse livro, 
utilizaremos o sistema operacional Windows para fazer o 
provisionamento do ambiente, utilizando o PowerShell como shell de 
linha de comando. O instalador do Azure CLI está disponível no 
endereço https://docs.microsoft.com/cli/azure/install-azure-cli- 
windows. 


Execute o pacote MSI e prossiga com a instalação padrão. Para 
verificar se a ferramenta foi instalada com sucesso, rode o comando 
az no PowerShell. 


PS C:\> az 

Welcome to Azure CLI! 

Use “az -hò to see available commands or go to https://aka.ms/cli. 
Telemetry 

The Azure CLI collects usage data in order to improve your experience. 


The data is anonymous and does not include commandline argument 
values. 


The data is collected by Microsoft. 


You can change your telemetry settings with "az configure”. 


a ae) ee 


[I d call 


Welcome to the cool new Azure CLI! 


Use `az --version to display the current version. 





Agora que possuímos a conta no Azure e a ferramenta necessária, 
o próximo passo é provisionar o ambiente na nuvem. 


2.3 Resumo 


Neste capítulo, introduzimos o cenário que motivou a adoção do 
Microsoft Azure pela empresa fictícia eShopOnWeb. Detalhamos a 


aplicação, apresentamos a arquitetura proposta para a nuvem, 
mostramos como criar uma conta no Azure e como configurar a 
ferramenta Azure CLI para acessar o ambiente na nuvem. No 
próximo capítulo, descreveremos como provisionar a infraestrutura 
necessária para hospedar essa aplicação no Azure. 


CAPITULO 3 
Provisionamento da infraestrutura 
Escrito por Alexandre Teoi e Luis Henrique Demetrio. 


No capítulo anterior, detalhamos como a aplicação eShopOnWeb 
funciona, descrevemos como criar uma conta no Azure e como 
obter e configurar a ferramenta Azure CLI para gerenciar o ambiente 
na nuvem. 


Neste capítulo, provisionaremos o ambiente através do método Lift 
& Shift. 


3.1 Criação dos recursos em nuvem 


O primeiro passo é abrir uma sessão do PowerShell e se autenticar 
no Azure através do comando az login: 


az login 


Nessa opção, a página de autenticação (https://aka.ms/devicelogin) 
será aberta no navegador para entrarmos as credenciais: 


Microsoft Azure 


B® Microsoft 
Sign in 


Email phone OF SKype 





No account? Create one! 
Can't access your account? 


Sign-in options 


= 


Figura 3.1: Página de autenticação do Azure. 


A seguinte mensagem é exibida no PowerShell caso a autenticação 
seja bem-sucedida: 


You have logged in. Now let us find all the subscriptions to which you 
have access... 

The following tenants don't contain accessible subscriptions. Use ‘az 
login --allow-no-subscriptions' to have tenant level access. 


XXXXXXXX-XXXX-XXXX-XXXX-XXXXXXXXXXXX 


[ 
{ 


"cloudName": "AzureCloud", 
"homeTenantId": "XXXXXXXX-XXXX-XXXX-XXXX-XXXXXXXXXXXX", 
"id": "XXXXXXXX-XXXX-XXXX-XXXX-XXXXXXXXXXXX", 
"isDefault": true, 
"managedByTenants": [], 
"name": "Avaliação Gratuita", 
"state": "Enabled", 
"tenantId": "XXXXXXXX-XXXX-XXXX-XXXX-XXXXXXXXXXXX", 
"user": { 

"name": "usuario@dominio.com", 

"type": "user" 





Grupo de recursos 


Agora que possuímos acesso ao Azure, precisamos criar um grupo 
de recursos (resource group, em inglês), que, como o próprio nome 
indica, serve para agrupar os recursos criados no Azure. Através 
dele é possível facilmente identificar, gerenciar e até mesmo excluir 
de uma única vez todos os recursos que fazem parte do grupo. 


Como a nossa aplicação é relativamente simples, criaremos todos 
os recursos em um único grupo. Os seguintes comandos serão 
utilizados para criar esse grupo com nome rg-eshoponweb na região 
Brazil South ( brazilsouth ). Toda a infraestrutura utilizada pela 
aplicação, como contas de armazenamento, rede, máquinas virtuais 
e banco de dados será criada dentro desse grupo. 


Utilizaremos a convenção de nomenclatura recomendada pela 
Microsoft para nomear os recursos no Azure. Essa convenção está 
disponível no seguinte endereço: 


https://docs.microsoft.com/azure/cloud-adoption- 
framework/ready/azure-best-practices/resource-naming 


# PowerShell 
$resourcegroup="rg-eshoponweb" 


az group create ` 
-l brazilsouth ` 
-n $resourcegroup 





Após executar o comando, as informações do grupo de recursos 
serão retornadas no formato JSON. A propriedade provisioningstate 
deverá ter o valor succeeded caso o grupo de recursos tenha sido 
provisionado com sucesso: 


"id": "/subscriptions/XXXXXXXX-XXXX-XXXX-XXXX- 
XXXXXXXXXXXX/resourceGroups/rg-eshoponweb", 

"location": "brazilsouth", 

"managedBy": null, 

"name": "“rg-eshoponweb", 


"properties": { 
"provisioningState": "Succeeded" 
>, 
"tags": null, 
"type": "Microsoft.Resources/resourceGroups 


} 





Conta de armazenamento 


Uma vez que temos o grupo de recursos criado, precisamos criar a 
conta de armazenamento que conterá os compartilhamentos de 
arquivos que precisam ser mapeados nos servidores. Além disso, 
utilizaremos essa mesma conta de armazenamento para criar um 
contêiner onde colocaremos os artefatos necessários para instalar e 
configurar a aplicação nos servidores. 


E l 
= = 5 = O | 

e B, eS : 
Artefatos de Produtos Proteção de | 
publicação Dados | 
l 

| 


| 
| 
| 
| 
| 
| 
| 
| 
| 
| Armazenamento =m 


Figura 3.2: Conta de armazenamento. 


Execute o comando a seguir para criá-la. Observe que utilizamos a 
variável resourcegroup , que contém o nome do grupo de recursos 
criado anteriormente, assim como definimos a nova variável 
storageaccountname COM O nome da conta de armazenamento para 
uso posterior. 


# PowerShell 


$storageaccountname="stdeploychee1" 
az storage account create ` 


-g $resourcegroup ` 

-n $storageaccountname ` 
-l brazilsouth ` 

--sku Standard_LRS ` 
--encryption-services blob 





Esse comando retornara um objeto JSON com os detalhes da conta 
de armazenamento criada. 


As imagens do catalogo de produtos sao armazenadas no 
subdiretório images/products da aplicação. Para que todas as 
instâncias de servidores Web tenham acesso ao mesmo conjunto de 
imagens, vamos armazená-lo em um compartilhamento de arquivos. 
O seguinte comando é utilizado para criar esse compartilhamento 
com o Nome products : 


# PowerShell 


az storage share create ` 


-n products ` 
--quota 10 ` 
--account-name $storageaccountname 





Na sequência, devemos criar mais um compartilhamento, que será 
utilizado para armazenar as chaves de criptografia que o módulo de 
proteção de dados do ASP.NET Core (ASP.NET Core Data 
Protection) utiliza para criptografar informações sensíveis, como os 
cookies de autenticação. Esse compartilhamento é necessário para 
que todos os servidores utilizem a mesma chave de criptografia, 
permitindo que um servidor decifre informações criptografadas por 
outro. 


# PowerShell 


az storage share create ` 


-n dataprotection ` 
--quota 10 ` 
--account-name $storageaccountname 





Através do portal do Azure é possível conferir os dois 
compartilhamentos de arquivos criados. 





Microsoft Azure (Versão prévia) É Pesquisar recursos, serviços e documer 


Página inicial > Grupos de recursos > rg-eshoponweb > stdeploych001 


E stdeploych001 | Compartilhamentos de arquivos 


Conta de armazenamento 














| P Pesquisar (Ctrl+/) | « “+ Compartilhamento de arquivos ©) Atualizar 
= Visão geral = Configurações de compartilhamento de arquivo 
bi) Log de atividade Active Directory: Não configurado Soft delete: | 
@ Marcações 

Pesquisar os compartilhamentos de arquivo por pret 
GZ Diagnosticar e resolver proble... 
Pa. IAM (Controle de Acesso) 


Nome 


Transferência de dados 


Q 


AM dataprotection 


MA 


Eventos 
e products 


== Gerenciador de Armazename... 


Figura 3.3: Compartilhamento de arquivos 


Com os compartilhamentos devidamente criados, precisamos 
configurar os acessos a eles. No script a seguir, os dois primeiros 
comandos obtêm o ID do locatário do Azure (que pode ser obtido via 
portal caso preferir através da opção active Directory do Azure > 
Propriedades > ID do locatário ) € O user principal name (UPN) do seu 
usuário. 


Microsoft Azure (Versão prévia) Æ Pesquisar recursos, serviços e documentos (G+/) 





Página inicial > Microsoft 


|! Microsoft | Propriedades & 

Í E | Active Directory do Azure 

O visão geral 

%] introdução Propriedades do locatário 
Hub de versão prévia 


X Diagnosticar e resolver proble... 


País ou região 


botera United States 
a Usuarios Local 
&& Grupos Asia, United States, Europe datacenters 


ĝ Funções e administradores 


r ZE É ID do Locatário 
& Unidades administrativas | 
| EE 


EE, Aplicativos empresariais 








Figura 3.4: ID do locatário 


O último comando do script é responsável por conceder a permissão 
para o seu usuário do Azure. Lembre-se de substituir o parâmetro 
subscription No comando az account show COMO nome da sua 
assinatura (esse nome pode ser obtido no retorno do comando az 
login ) e colocar o seu e-mail no comando az ad user list. 


# PowerShell 


$id = az account show ` 
--subscription "Avaliação Gratuita" ` 
--query id ` 


--output tsv 


$upn = az ad user list 
--query "[ ?otherMails[ ?@=='usuario@dominio.com']]. 
[userPrincipalName ][0][0] 


--output tsv 


az ad signed-in-user show ~ 

--query objectId ` 

-o tsv | 

az role assignment create ~ 

--role "Storage Blob Data Contributor" ~ 

--assignee $upn ` 

--scope "/subscriptions/$id/resourceGroups/rg- 
eshoponweb/providers/Microsoft.Storage/storageAccounts/$storageaccount 
name" 





Os detalhes do acesso serao retornados no formato JSON, mas 
também é possível obter maiores detalhes no portal do Azure: 


Pagina inicial > steshoponweb001 


Ra steshoponweb001 | IAM (Controle de Acesso) 


Conta de armazenamento 


Ø Pesquisar (Ctrl+/) | « + Adicionar d Baixar as atribuições da função 





= Visão geral 
Verificar acesso Atribuições de função Funções = Atribuiçé 


Log de atividade 
Ç Marcações Número de atribuições de função desta assinatura 
| 
P Diagnosticar e resolver proble... 1 2000 
a, IAM (Controle de Acesso) 
E | Pesquisar por nome ou e... Tipo : Tudo Função : Tudo 
E Transferência de dados 
Ë Eventos 1 itens (1 Usuários) 
às Gerenciador de Armazename... LJ Nome Tipo 


e = Colaborador de Dados do Storage Blob 
Configurações 


f chaves de acesso LJ ® Usuário 
E Replicação Geográfica 


E) CORS 


Figura 3.5: Controle de acesso 


Já podemos subir as imagens dos produtos localizados no diretório 
C:\Repos\ eShopOnWeb\ src\Web\wwwroot\images\products para O 
compartilhamento do arquivo products criado anteriormente. A 
primeira instrução do script é utilizada para obter a chave para 
autorizar o acesso à conta de armazenamento: 


# PowerShell 


$accountkey = az storage account keys list ` 
-g $resourcegroup ` 
-n $storageaccountname ` 


--query "[@].value" 


az storage file upload-batch ` 
--account-name $storageaccountname ` 
--account-key $accountkey ` 
--pattern *.png ` 
--source "C:\Repos\eShopOnwWeb\ src\Web\wwwroot\ images\ products" ` 
--destination 
"https: //$storageaccountname. file. core.windows.net/products" 





O ultimo recurso que criaremos nessa conta de armazenamento é 
um contéiner que sera usado para armazenar os artefatos 
necessários para a publicação da aplicação. 

# PowerShell 


$storagecontainer = "stcdeploychee1" 


az storage container create ` 


-n $storagecontainer ~ 


--account-name $storageaccountname ` 
--public-access off ` 
--auth-mode login 





Provisionamento do banco de dados 


A aplicação utiliza o banco de dados Microsoft SQL Server 2019 
para armazenar as informações do site, como dados de clientes e 
produtos comercializados no site. Apesar de estarmos utilizando a 


abordagem Lift & Shift para a aplicação, provisionaremos o banco 
de dados através do serviço Azure SQL Database na modalidade 
de plataforma como serviço (PaaS - Platform as a Service), o que 
proporcionará uma melhora significativa no tempo que seria 
necessário para provisionar o servidor de banco de dados. 


Utilizando o comando a seguir, provisionaremos o Azure SQL Server 
no grupo de recursos criado anteriormente e definiremos as 
credenciais do usuário administrador. 


# PowerShell 
$sqlservername = "sql-eshoponweb-ch-001" 


az sql server create ` 


-g $resourcegroup ` 

-n $sqlservername ` 

-l brazilsouth ` 

--admin-user eshopadmin ` 
--admin-password s3nh@Comple*4 





O comando retornará os detalhes do recurso que foi provisionado no 
formato JSON. É importante que o valor da propriedade 
provisioningState tenha o valor Succeeded . Através do portal do Azure 
também é possível verificar que o servidor de banco de dados foi 
provisionado com sucesso: 


E sql-eshoponweb-ch-010 d 


SQL Server 


Pesquisar (Ctrl+/) < ++ Criar banco de dados “+ Novo pool elástico + Novo pool de SQL do Synapse (data warehouse) d Importar 





^AN Fundamentos 


E visão geral 
ZE Grupo de recursos (alterar) Administrador do servidor 

a Log de atividade ae b ) A ; 
rg-eshoponweb eshopadmin 

Ba IAM (Controle de acesso) Status Firewalls e redes virtuais 
Disponivel Mostrar configurações de firewall 

o Marcações 
Local Administrador do Active Directory 

ES Diagnosticar e resolver proble... Sul do Brasil Não configurado 
Assinatura (alterar) Nome do servidor 

Configurações Avaliação Gratuita sql-eshoponweb-ch-010.database.windows.net 


& Inicio rápido ID da Assinatura 
5b5095a9-bbfc-40e2-875a-74e087 186f14 


E Grupos de failover 
Marcações (alterar) 


@ Gerenciar Backups Clique aqui para adicionar marcações 
SO Active Directory administrado... Notificações (0) Recursos (6) 
ye de dados SQL 
E Bancos dedados S ( Todos | Segurança (4) Desempenho (1) Recuperação (1) ) 
4 Pools elásticos do SQL 
e ZE e : 
E e Administrador do Active Directory 
W Bancos de dados excluídos a 0 Azure Defender para SQL 


Permite que vocé gerencie de forma centralizada a 
rae fe aerated ae ZO 


Gr HictAricn de Imnartacan/Fyna = ae oe ees pere de dedi 


Avaliação de Vulnerabilidades e Proteção 


Figura 3.6: Azure SQL Server provisionado. 


Para que a aplicação consiga acessar o banco de dados, é 
necessário criar uma regra de firewall através do seguinte 
comando. Como estamos passando o valor 0.0.0.0 para os 
parâmetros start-ip-address € end-ip-address , essa regra libera o 
acesso ao banco de dados para todos os endereços IPs internos do 
Azure. 


# PowerShell 


az sql server firewall-rule create 


-g $resourcegroup ` 


-n sqlfw-allowazureips-ch-001 
-s $sqlservername 
--start-ip-address 0.0.0.0 ` 
--end-ip-address 0.0.0.0 





Segue o resultado JSON, que é esperado como retorno: 


"endIpAddress": "0.0.0.0", 
"id": "/subscriptions/xxxXXXXX-XXXX-XXXX-XXXX- 


XXXXXXXXXxxX/resourceGroups/rg- 


eshoponweb/providers/Microsoft.Sql/servers/sql-eshoponweb-ch- 
001/firewallRules/sqlfw-allowazureips-ch-001", 

"kind": "v12.0", 

"location": "Brazil South", 

"name": “sqlfw-allowazureips-ch-001", 

"resourceGroup": "rg-eshoponweb", 

"startIpAddress": "0.0.0.0", 

"type": "Microsoft.Sql/servers/firewallRules" 


} 





Com o servidor SQL Server provisionado, é possível criar os dois 
bancos de dados, sendo o primeiro para o catálogo de produtos 
( CatalogDb ) e O Segundo para controle de usuários ( Identity ): 


# PowerShell 


az sql db create ~ 
-g $resourcegroup ~ 
Microsoft.eShopOnWeb.CatalogDb ~ 
$sqlservername ~ 
Basic 


db create ` 


$resourcegroup ` 
Microsoft.eShopOnWeb.Identity ` 
$sqlservername ~ 

Basic 





O comando retornará os detalhes no formato JSON, assim como é 
possível consultar os detalhes no portal do Azure: 


Pagina inicial 


A Pesquisar (Ctrl+/) « 


SQL Server 


E visão geral 
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2 Diagnosticar e resolver proble... 


Log de atividade 
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Configurações 
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Inicio rapido 

Grupos de failover 

Gerenciar Backups 
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Bancos de dados SQL 

Pools elasticos do SQL 
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DO Azure Defender para SQL 


Avaliação de Vulnerabilidades e Proteção 
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3 bancos de dados 


Nome TL Tipo Ty 
Banco de dados SQL 

Microsoft.eShopOnWeb.CatalogDb Banco de dados SQL 

Microsoft.eShopOnWeb.Identity Banco de dados SQL 


Figura 3.7: Bancos de dados CatalogDb e Identity 


Uma vez que os bancos de dados estão disponíveis, podemos criar 
seus objetos. A primeira etapa é liberar no firewall o acesso da 
estação de desenvolvimento local. Assim, é necessário obter o seu 
endereço IP público. Existem alguns serviços disponíveis na 
internet, como o https://domains.google.com/checkip, que retorna 
essa informação. Execute o seguinte comando para liberar o 
firewall: 


# PowerShell 


$meulP=curl -4 https://domains.google.com/checkip 


az sql server firewall-rule create ~ 
-g $resourcegroup ` 
-n sqlfw-allowlocalmachine ` 
-s $sqlservername ` 
--start-ip-address $meuIP ` 
--end-ip-address $meuIP 





Existem diversas ferramentas para executar consultas no SQL 
Server, como o Microsoft SQL Server Management Studio ou o 
próprio Microsoft Visual Studio. Como já estamos utilizando o Visual 
Studio como editor da aplicação, vamos utilizá-lo aqui também. 


No Visual Studio, através da janela Server Explorer ( ctrl+alt+s ), 
devemos clicar em Connect to Database para configurar a conexão 
com o banco de dados: 
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É App Service 
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Figura 3.8: Server Explorer do Visual Studio. 


Informe os seguintes dados, que foram criados anteriormente, para 
testarmos a conexão com o banco de dados e clique no botão Test 
Connection: 


e Nome do servidor: sql-eshoponweb-ch-001.database.windows.net 
(utilize aqui o nome do seu SQL Server) 

e Autenticação: SQL Server Authentication 

e Nome do usuário: eshopadmin 

e Senha: s3nh@Comple\ EA 





Enter information to connect to the selected data source or click “Change” to choose a 
different data source and/or provider. 


Data source: 


Microsoft SQL Server (SqlClient) Change... 


Server name: 


sql-eshoponweb-ch-010.database.windows.net v Refresh 














Log on to the server 





Authentication: SQL Server Authentication v 


User name: |eshopadmin 


C] Save my password 








Connect to a database 


@ Select or enter a database name: 


©) Attach a database file: 


Logical name: 


Advanced... | 


TZ come | 











Figura 3.9: Configuragao da conexao com o Azure SQL Server. 


Se toda a configuração tiver sido realizada com sucesso, sera 
exibida a mensagem de Test connection succeeded. Então clique 
em OK. Antes de concluir, selecione o banco de dados master e 
clique em OK para criar a conexão. Repita esse procedimento para 
os outros bancos de dados (CatalogDb e Identity). 


Add Connection 


Enter information to connect to the selected data source or click “Change” to choose a 
different data source and/or provider. 


Data source: 

Microsoft SQL Server (SqlClient) | Change.. 
Server name: 

sql-eshoponweb-ch-010.database.windows.net v | Refresh 


Log on to the server 


Authentication: SQL Server Authentication 





ssa 


L] Save my password 
Connect to a database 


@ Select or enter a database name: 






master 
O Microsoft.eShopOnWeb.CatalogDb 
Microsoft.eShopOnWeb.Identity 


Logical name: 


| Advanced... 














Test Connection | E Cancel 





Figura 3.10: Selegao do banco de dados. 
Criagao do usuario de aplicagao 


Por motivos de segurança, a aplicação deve utilizar um usuário nao 
administrativo para acessar o banco de dados. Para isso, vamos 
criar um usuário SQL chamado eshopweb e adicioná-lo aos grupos 
db datareader € db datawriter dos bancos de dados da aplicação. 


No Visual Studio, crie uma consulta no banco de dados master para 
criar o usuário. Use o botão direito do mouse no banco de dados 
master e selecione a opção New Query. 


DO File Edit View Git Project Build Debug 


e E e E Da - - | Debug ~ 


erver Explorer 


xogjool 





AA Azure (i ~ om D subscriptions) 
+ JI Data Lake Analytics 

> saz HD Insight 

> EN Stream Analytics 

> E Virtual Machines 

a g? Data Connections 





“a sql-eshoponweb-ch-001 .master.dbo 












© Refresh 

X Delete Del 
Change View 
Modify Connection... 
Close Connection 
New Query 
Browse In SQL Server Object Explorer 
Rename 


Alt+Enter 





Fº Properties 


Figura 3.11: Criagao de consulta. 


Execute a seguinte instrução para criar um usuário chamado 
eshopweb COM senha Senh4supersecreta : 


CREATE LOGIN [eshopweb] WITH PASSWORD=N'Senh4supersecre+a' 





Para mapear esse usuario nos bancos de dados de catalogo e 
identidade e dar os acessos necessarios, crie uma consulta para 
cada um desses bancos com as seguintes instruções: 


CREATE USER [eshopweb] FOR LOGIN [eshopweb] 
WITH DEFAULT SCHEMA=[dbo] 
GO 


ALTER ROLE [db datareader] ADD MEMBER [eshopweb] 
GO 


ALTER ROLE [db datawriter] ADD MEMBER [eshopweb] 
GO 





Criação das tabelas do banco de dados 


Para criar as tabelas necessárias no banco de dados para executar 
a aplicação, utilizaremos a ferramenta do Entity Framework Core. 
Para instala-la, execute o seguinte comando no PowerShell: 


# PowerShell 


dotnet tool install --global dotnet-ef 





O Entity Framework Core é um mapeador do modelo de objetos de 
uma aplicação e do modelo relacional do banco de dados (ORM, 
Object-Relational Mapping). Além de ser multiplataforma, ele 
encapsula o acesso ao banco de dados, permitindo ao 
desenvolvedor realizar as consultas na linguagem de 
desenvolvimento de sua preferência. Maiores detalhes em: 
https://docs.microsoft.com/ef/core. 


Com isso, vá para o diretório c:\Repos\eShopOnWeb\src\Web e execute 
os seguintes comandos para gerar os scripts de criação das tabelas: 


# PowerShell 
cd C:\Repos\eShopOnwWeb\ src\Web 


dotnet restore 
dotnet tool restore 


$env: ASPNETCORE ENVIRONMENT='Production' 


dotnet ef dbcontext script ` 
-c catalogcontext ` 


-p ../Infrastructure/Infrastructure.csproj ` 
-s Web.csproj ` 

--configuration Release ` 

-o C:\Temp\catalog.sql 


dotnet ef dbcontext script ` 
-c appidentitydbcontext ` 
-p ../Infrastructure/Infrastructure.csproj ` 
-s Web.csproj ` 
--configuration Release ` 
-o C:\Temp\identity.sql 





Esses comandos criam os scripts catalog.sql € identity.sql NO 
diretório C:\Temp . 


Utilizando o mesmo procedimento descrito anteriormente, para 
executar os comandos de criação de usuário, execute os scripts 
catalog.sql € identity.sql nos bancos de dados CatalogDb e 
Identity respectivamente para criar as tabelas. 


Máquinas Virtuais 


Dando continuidade ao uso das funcionalidades do Azure, vamos 
provisionar os servidores da aplicação (máquinas virtuais) através 
do serviço Virtual Machine Scale Set, que foi traduzido como 
conjunto de escalas da máquina virtual. Esse serviço permite 
dimensionar o número de VMs manualmente ou definir regras para 
o escalonamento automático com base no uso de recursos dos 
servidores, como CPU, memória ou tráfego de rede. 


Através do seguinte comando provisionaremos um Virtual Machine 
Scale Set com o sistema operacional Ubuntu. Definimos também 
nesse comando o nome do usuário administrador (eshopadmin). 


# PowerShell 
$scalesetname = "vmss-web-ch-001" 


az vmss create ` 


-g $resourcegroup ` 
-n $scalesetname ` 
--image UbuntuLTS ` 
--upgrade-policy-mode automatic ` 


--admin-username eshopadmin ` 
--generate-ssh-keys 





Além do resultado JSON, podemos visualizar no portal do Azure que 
o conjunto de escalas da máquina virtual foi criado com sucesso. 


Pagina inicial > rg-eshoponweb > 
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Conjunto de escalas da máquina virtual 
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Figura 3.12: Virtual Machine Scale Set. 


Também é possível verificar que, por padrão, duas instâncias de 
máquinas virtuais foram provisionadas. 





Página inicial > rg-eshoponweb > vmss-web-ch-001 
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Figura 3.13: Instâncias do Scale Set. 


Como utilizamos a opção generate-ssh-keys Na criação do conjunto 
de escalas, um par de chaves SSH (id rsa € id rsa.pub ) será 
gerado no diretório ¢HomE\.ssh . Com a chave privada desse par é 


possível conectar nas instâncias do conjunto de escalas através da 
ferramenta ssh. Para fazer essa conexão, precisamos criar uma 
máquina virtual de administração na mesma rede do conjunto de 
escalas. Por padrão, o nome da rede de um conjunto de escalas é o 
seu nome com o sufixo VNET e o nome da sub-rede terá sufixo 
Subnet. Por exemplo, se o conjunto de escalas tem o nome vmss- 
web-ch-001, o nome da rede será vmss-web-ch-001VNET e a sub- 
rede sera vmss-web-ch-001 Subnet. 


Execute o seguinte comando para criar uma maquina virtual de 
administração nessa rede virtual com usuário administrador 
chamado eshopadmin. O parâmetro public-ip-address-dns-name 
precisa ser alterado para um nome DNS que não esteja em uso na 
região. Nesse exemplo, como utilizamos a região brazilsouth , a 
máquina estará disponível no endereço 


vmeshopadmin.brazilsouth.cloudapp.azure.com. 


# PowerShell 


az vm create ` 
-g $resourcegroup ` 
-n vmeshopadmin ` 
--image UbuntuLTS ` 
--vnet-name "$($scalesetname)VNET" ` 
--subnet "$($scalesetname)Subnet" ` 
--location brazilsouth ` 


--public-ip-address-dns-name vmeshopadmin ` 
--admin-username eshopadmin 





Com a máquina criada, podemos nos conectar a ela através da 
ferramenta ssh. As versões mais recentes do Windows 10 
disponibilizam o cliente OpenSSH como pacote opcional. Utilize o 
comando Get-wWindowsCapability do PowerShell para pegar o nome 
desse pacote: 


# PowerShell 


Get-WindowsCapability -Online | ? Name -like 'OpenssH*' 


# Esse deve ser o resultado do comando: 


Name : OpenSSH.Client~~~~@.0.1.0 
State : NotPresent 
Name : OpenSSH. Servere-<~-0.0.1.0 
State : NotPresent 





Para instalar o pacote, inicie o PowerShell como administrador e 
execute o comando Add-WindowsCapability . 


# PowerShell 


Add-WindowsCapability -Online -Name OpenSSH.Client~~~~@.0.1.0 





Com o cliente OpenSSH instalado, copie o par de chaves SSH, 
criado na estação local, para o diretório ~/.ssh da estação 
administrativa com o comando scp. 


# PowerShell 


scp $HOME\.ssh\id_rsa* ` 
eshopadmin@vmeshopadmin.brazilsouth.cloudapp.azure.com:~/.ssh 





Para listar os endereços IPs das instâncias do nosso conjunto de 
escalas, execute o seguinte comando: 


# PowerShell 


az vmss nic list ` 


-g $resourcegroup ` 
--vmss-name $scalesetname ` 
--query [].ipConfigurations[].privateIpAddress 





Esse comando deve retornar uma matriz JSON com os endereços 
IPs de todas as instâncias: 





Execute o seguinte comando para se conectar à estação de 
administração: 


# PowerShell 


ssh eshopadmin@vmeshopadmin.brazilsouth.cloudapp.azure.com 





Dentro da estação de administração, precisamos proteger as chaves 
com o comando chmod para que possam ser utilizadas pela 
ferramenta ssh. 


# bash 
# Execute o comando abaixo na estacao de administracao 


chmod 600 ~/.ssh/id_rsa* 





Finalmente, podemos conectar a uma instancia do conjunto de 
escalas através do comando ssh utilizando os endereços IP obtidos 
anteriormente com o comando az vmss nic list: 


# bash 
# Execute o comando abaixo na estacao de administração 
# Substitua o endereço IP com um dos IPs das suas instâncias 


ssh eshopadmin@10.1.0.4 





DNS 


Até este momento, a única maneira de acessar as máquinas é 
através do IP público. Visando facilitar o acesso, o próximo passo é 
configurar um nome público no DNS. A primeira parte do comando a 
seguir é utilizada para obter o recurso Endereço IP público do 
conjunto de escalas. Já a segunda parte configura o nome no DNS 
para o IP público. Antes de executar, substitua o valor da variável 
dnsName COM UM nome que não esteja em uso na região onde você 
criou seu conjunto de escalas. 


# PowerShell 
$dnsName = “eshoponwebchee1i" 


$publicip = az network public-ip list ` 
-g $resourcegroup ` 


--query "[?contains(name, '$scalesetname')].name" 
ConvertFrom-Json 


az network public-ip update ` 
-g $resourcegroup ` 
-n $publicip ` 
--dns-name $dnsName 





Através do portal, podemos verificar se o nome DNS foi 
corretamente configurado: 


vmss-web-ch-001LBPubliclP <2 & 


Endereço IP público 
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Figura 3.14: Configuração do endereço IP 
Dimensionamento automático 


Nesta etapa, será configurado o dimensionamento automático dos 
servidores de acordo com a utilização de CPU. Através do seguinte 
comando, habilitamos o dimensionamento automático para ter no 
mínimo duas instâncias e no máximo três. 


# PowerShell 


gautoscalename = "“autoscaleCPU" 


az monitor autoscale create ` 
-g $resourcegroup ` 


-n $autoscalename ` 

--resource $scalesetname ` 

--resource-type Microsoft.Compute/virtualMachineScaleSets ` 
--min-count 2 ` 

--max-count 3 ` 

--count 2 





Ja as regras para aumentar ou diminuir o numero de instâncias sao 
definidas através dos seguintes comandos: 


# PowerShell 


az monitor autoscale rule create ~ 
-g $resourcegroup ` 
--autoscale-name $autoscalename ` 
--condition "Percentage CPU > 70 avg 5m" ` 
--scale out 1 


az monitor autoscale rule create ` 
-g $resourcegroup ` 


--autoscale-name $autoscalename ` 
--condition "Percentage CPU < 30 avg 5m" ` 
--scale in 1 





Caso o servidor permaneça com um consumo médio superior a 70% 
de processamento por um período de cinco minutos, o número de 
instâncias aumentará. Já caso o percentual de processamento seja 


inferior a 30% durante cinco minutos, o numero de instancias sera 
reduzido. 


GQ 
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Figura 3.15: Configuração de escalonamento. 


3.2 Resumo 


Neste capítulo, mostramos como montar uma infraestrutura no 
Azure utilizando somente a ferramenta Azure CLI. Aqui já podemos 
perceber alguns benefícios do ambiente em nuvem: 


e Facilidade para subir de forma rápida uma infraestrutura 
complexa. 

e Aumento e diminuição automáticos dos recursos de 
processamento através de gatilhos configuráveis. 


CAPITULO 4 
Publicação da aplicação 


Escrito por Alexandre Teoi e Luis Henrique Demetrio. 


No capítulo anterior, montamos a infraestrutura no Azure que vai 
receber a nossa aplicação. Nesse ambiente, criamos um Virtual 
Machine Scale Set, que nos fornece um número configurável de 
máquinas virtuais onde instalaremos os módulos da aplicação. 


Antes de publicar a aplicação, precisamos adaptá-la para que ela 
possa ser executada no ambiente escalável, que criamos. Feita a 
adaptação, podemos publicá-la executando os seguintes passos em 
cada instância do nosso Virtual Machine Scale Set. Utilize a 
máquina virtual de administração que criamos no capítulo anterior 
para se conectar em cada instância do conjunto de escalas para 
executar estes passos: 


e Instalar o ambiente de execução (runtime) do ASP.NET Core 

3.1. 

Instalar o pacote NGINX. 

e Publicar o módulo Web. 

e Publicar o módulo PublicAPI. 

e Mapear o compartilhamento de arquivos do módulo de proteção 
de dados. 

e Mapear o compartilhamento de arquivos das fotos dos 

produtos. 

Iniciar as aplicações Web e PublicAPI. 

Configurar o NGINX para atuar como proxy reverso das 

aplicações WEB e PublicAPI. 

Configurar o balanceador de carga. 


4.1 Adaptação da aplicação 


Para publicar a aplicação no nosso ambiente em nuvem, devemos 
fazer as seguintes adaptações na versão original: 


e Reconhecer os cabeçalhos HTTP X-Forwarded-For e X- 
Forwarded-Proto enviados pelo servidor de proxy reverso 
NGINX para informar o endereço IP do cliente e protocolo 
(HTTP ou HTTPS) utilizados na requisição original. 

e Armazenar a chave de criptografia do módulo de proteção de 
dados do ASP.NET Core em um diretório compartilhado. 

e Armazenar as fotos dos produtos em um diretório 
compartilhado. 

e Configurar strings de conexão com o banco de dados. 


X-Forwarded-For e X-Forwarded-Proto 


Para que a aplicação tenha acesso ao endereço IP do cliente e 
protocolo utilizados na requisição, precisamos configurar o ASP.NET 
Core para reconhecer os cabeçalhos HTTP X-Forwarded-For e X- 
Forwarded-Proto. Caso contrário, o endereço IP do cliente recebido 
pela aplicação será sempre o do servidor de proxy reverso NGINX. 
Como o NGINX roda no mesmo servidor da aplicação, esse 
endereço será sempre o localhost. A nossa aplicação exemplo não 
utiliza essas informações, mas aplicações reais normalmente 
precisam delas para, por exemplo, implementar controles de 
segurança. 


A alteração para reconhecer esses cabeçalhos deve ser feita no 
método configure da classe startup do projeto Web, por meio da 
chamada do método IApplicationBuilder.UseForwardedHeaders . 


public void Configure( 
IApplicationBuilder app, 
IWebHostEnvironment env) 


app.UseForwardedHeaders (new ForwardedHeadersOptions 


{ 


ForwardedHeaders = ForwardedHeaders.XForwardedFor 


| ForwardedHeaders .XForwardedProto 


}); 


app.UseCookiePolicy(); 
app.UseAuthentication(); 
app.UseAuthorization() ; 





Chave de criptografia 


A chave de criptografia do módulo de proteção de dados do 
ASP.NET Core deve ser compartilhada entre todas as instâncias do 
conjunto de escalas. Para isso, utilizaremos o compartilhamento de 
arquivos na conta de armazenamento do Azure, que criamos no 
capítulo anterior. Na seção Compartilhamento de arquivos do 
módulo de proteção de dados deste capítulo, descrevemos como 
efetuar o mapeamento desse compartilhamento de arquivos nas 
máquinas virtuais. 


Para que a aplicação busque a chave de criptografia nesse diretório 
mapeado, o projeto Web precisa chamar o método 
IApplicationBuilder.PersistKeysToFileSystem NO método 
ConfigureProductionservices da classe startup . Na nossa 
implementação, o caminho do diretório será configurado através da 
seção DataProtectionPath do arquivo de configuração 


appsettings.json. 


public void ConfigureProductionServices( 
IServiceCollection services) 


services .AddDataProtection() 
.PersistKeysToFileSystem(new DirectoryInfo( 
Configuration.GetSection("DataProtectionPath").Value) 
)5 





O script de instalação, que descreveremos adiante, mapeará o 
compartilhamento de arquivo no diretório /mnt/dataprotection . 


Assim, precisamos adicionar a seção DataProtectionPath ao arquivo 
appsettings.Production.json dO projeto Web: 


{ 
"DataProtectionPath": "/mnt/dataprotection", 
"baseUrls": { 
"webBase": "http://localhost:8000/" 


>, 





Fotos dos produtos 


A aplicação armazena as fotos dos produtos no subdiretório 
images/products da aplicação Web. Para que as fotos dos novos 
produtos cadastrados sejam compartilhadas entre todas as 
instâncias do conjunto de escalas, vamos mapear esse diretório no 
compartilhamento de arquivos products criado anteriormente. Na 
seção Compartilhamento de arquivos das fotos dos produtos deste 


capítulo, descrevemos como efetuar o mapeamento desse 
compartilhamento de arquivos nas máquinas virtuais. 


Strings de conexão 


Os projetos Web e PublicAPI precisam acessar o banco de dados. 
As strings de conexão com o banco para o ambiente de produção 
estão armazenadas no arquivo appsettings.Production.json desses 
projetos. Altere as strings de conexão nesses arquivos com as 
informações do banco de dados criado anteriormente. 


"ConnectionStrings": { 
"CatalogConnection": "Server=tcp:<servidor>, 1433; Initial 
Catalog=Microsoft.eShopOnWeb.CatalogDb;Persist Security 
Info=False;User ID=eshopweb; Password=Senh4supersecre+a; 


MultipleActiveResultSets=False;Encrypt=True;TrustServerCertificate=Fal 
se;Connection Timeout=30;", 

"IdentityConnection": "Server=tcp:<servidor>,1433; Initial 
Catalog=Microsoft.eShopOnWeb.Identity;Persist Security Info=False;User 
ID=eshopweb ; Password=Senh4supersecre+a; 


MultipleActiveResultSets=False;Encrypt=True;TrustServerCertificate=Fal 
se;Connection Timeout=30;" 


} 





4.2 Publicagao 


Agora que temos a aplicação adaptada para rodar no ambiente 
criado, podemos iniciar o seu processo de publicação. Lembre-se de 
que esse processo deve ser executado nas instâncias de máquinas 


virtuais do nosso conjunto de escala. Para acessar essas maquinas, 
precisamos utilizar a estagao de administragao como ponte, 
conforme descrito no capitulo anterior. 





Estação de 


Estação Local Administração 


Rede Virtual 


Figura 4.1: Acesso às instâncias de máquinas virtuais. 
Instalação do ASP.NET Core 3.1 


A instalação do ambiente de execução do ASP.NET Core 3.1 em 
servidores Ubuntu é feita através dos comandos: 


# bash 
# Execute esses comandos em todas as instancias do conjunto de escala 


wget https://packages.microsoft.com/config/ubuntu/18.04/packages- 
microsoft-prod.deb -O packages-microsoft-prod.deb 


sudo dpkg -i packages-microsoft-prod.deb 

sudo apt-get update 

sudo apt-get upgrade -y 

sudo apt-get install -y apt-transport-https 
sudo apt-get install -y aspnetcore-runtime-3.1 
sudo apt-get autoremove -y 





Instalação do NGINX 
O servidor de proxy reverso NGINX é instalado com os seguintes 


comandos: 


# bash 
# Execute esses comandos em todas as instancias do conjunto de escala 


sudo apt-get install -y nginx 
sudo service nginx start 





Publicagao do modulo Web 


Para publicar o modulo Web, devemos gerar os arquivos de 
publicação do projeto Web e, para facilitar a transferência para os 
servidores, compactá-los com a ferramenta tar . Para isso, no 
PowerShell Navegue até o diretório C:\Repos\eShopOnWeb\src\Web € 
execute os seguintes comandos. Após gerar o pacote, copie-o para 
a estação de administração com o comando scp. 


# PowerShell 
# Execute esses comandos na estacao de desenvolvimento 


cd C:\Repos\eShopOnwWeb\ src\Web 


dotnet publish -c Release 

tar -czvf C:\temp\web.tar.gz ` 
-C bin/Release/netcoreapp3.1/publish . 

scp C:\temp\web.tar.gz ` 
eshopadmin@vmeshopadmin.brazilsouth.cloudapp.azure.com:~/ 





Com o pacote na estação de administração, podemos copiá-lo para 
as instâncias do conjunto de escalas com o mesmo comando scp. 


# bash 
# Execute esse comando na estacao de administracao 
# Repita para todas as instancias do conjunto de escala 


scp ~/web.tar.gz eshopadmin@10.1.0.4:~/ 





Com o pacote copiado para as instâncias, podemos descompacta-lo 
com os comandos: 


# bash 
# Execute esses comandos em todas as instancias do conjunto de escala 


sudo mkdir -p /var/www/eshoponweb/web 


sudo tar -xzvf ~/web.tar.gz -C /var/www/eshoponweb/web 
sudo chown -R www-data:www-data /var/www/eshoponweb/web 





Para gerenciar a aplicação Web, utilizaremos o gerenciador de 
serviços systemd (https://github.com/systemd/systemd) do Linux, 


como descrito no guia Host ASP.NET Core on Linux with Nginx 
(https://docs.microsoft.com/aspnet/core/host-and-deploy/linux- 
nginx). 


A configuração de um serviço gerenciado pelo systemd é feita 
através de arquivos unit (unit files). Para a aplicação Web, devemos 
criar um arquivo chamado kestrel-web.service no diretório 
/etc/systemd/system em todas as instâncias do conjunto de escalas 
com o seguinte conteúdo: 


[Unit] 
Description=eShopOnWeb Web 


[Service] 

WorkingDirectory=/var/www/eshoponweb/web 
ExecStart=/usr/bin/dotnet /var/www/eshoponweb/web/Web.d11 
Restart=always 

# Reinicia o serviço após 10 segundos caso de falha do processo 
dotnet: 

RestartSec=10 


KillSignal=SIGINT 
SyslogIdentifier=eshoponweb-web 

User=www-data 
Environment=ASPNETCORE_ENVIRONMENT=Production 
Environment=DOTNET_PRINT_TELEMETRY_MESSAGE=false 
Environment=ASPNETCORE_URLS=http://* : 8000 


[Install] 
WantedBy=multi-user.target 





Essa configuração vai executar a aplicação Web instalada no 
diretório /var/www/eshoponweb/web NO contexto do usuário www-data e 
responderá na porta TCP 8000. O usuário www-data é criado pelo 
NGINX. 


Para habilitar o serviço Web, basta utilizar o comando systemct1 : 


# bash 
# Execute esse comando em todas as instancias do conjunto de escala 


sudo systemctl enable kestrel-web.service 





Publicagao da API 


A publicação da API segue os mesmos passos da publicação do 
módulo Web. Para gerar o pacote de publicação, navegue para o 
diretório c:\Repos\eShopOnWeb\ src\PublicApi NO PowerShell e execute 
os comandos: 


# PowerShell 
# Execute esses comandos na estacao de desenvolvimento 


cd C:\Repos\eShopOnWeb\ src\ PublicApi 

dotnet publish -c Release 

tar -czvf C:\temp\api.tar.gz ` 
-C bin/Release/netcoreapp3.1/publish . 

scp C:\temp\web.tar.gz ` 
eshopadmin@vmeshopadmin.brazilsouth.cloudapp.azure.com:~/ 





Após gerar o pacote e copiá-lo para a estação de administração, 
transfira para as instâncias do conjunto de escala: 


# bash 
# Execute esse comando na estacao de administracao 


# Repita para todas as instancias do conjunto de escala 


scp ~/api.tar.gz eshopadmin@10.1.0.4:~/ 





Feita a transferência, o pacote pode ser descompactado com os 
comandos: 


# bash 
# Execute esses comandos em todas as instancias do conjunto de escala 


sudo mkdir -p /var/www/eshoponweb/api 
sudo tar -xzvf ~/api.tar.gz -C /var/www/eshoponweb/api 
sudo chown -R www-data:www-data /var/www/eshoponweb/api 





Utilizaremos o seguinte arquivo unit para configurar a API no 
systemd. Ele deve ter o nome kestrel-api.service e precisa estar no 
diretório /etc/systemd/system de todas as instâncias do conjunto de 
escalas. 


[Unit] 
Description=eShopOnWeb API 


[Service] 
WorkingDirectory=/var/www/eshoponweb/api 
ExecStart=/usr/bin/dotnet /var/www/eshoponweb/api/PublicApi.d1l 
Restart=always 

# Reinicia o serviço após 10 segundos 

# em caso de falha do processo dotnet: 
RestartSec=10 

KillSignal=SIGINT 
SyslogIdentifier=eshoponweb-api 

User=www-data 
Environment=ASPNETCORE_ENVIRONMENT=Production 
Environment=DOTNET_PRINT_TELEMETRY_MESSAGE=false 
Environment=ASPNETCORE_URLS=http://* : 9000 


[Install] 
WantedBy=multi-user.target 





Essa configuração vai executar a API instalada no diretório 
/var/www/eshoponweb/api NO contexto do usuário www-data e 
responderá na porta TCP 9000. 


Para habilitar a API, devemos utilizar o comando systemctl : 


# bash 
# Execute esse comando em todas as instancias do conjunto de escala 


sudo systemctl enable kestrel-api.service 





Compartilhamento de arquivos do modulo de protegao de 
dados 


Para que as instâncias do conjunto de escalas utilizem a mesma 
chave de criptografia, precisamos armazená-la em um diretório 
compartilhado. Para mapear o diretório nas instâncias, usaremos o 
protocolo SMB (Server Message Block) como descrito no guia Use 
Azure Files with Linux, disponível em 
https://docs.microsoft.com/azure/storage/files/storage-how-to-use- 
files-linux. 


Para acessar o compartilhamento de arquivo na conta de 
armazenamento do Azure, precisamos da chave de acesso da conta 
de armazenamento, que criamos anteriormente. Utilize o seguinte 
comando Azure CLI para buscar essa chave: 


# PowerShell 


az storage account keys list ` 


-g $resourcegroup ` 
-n $storageaccountname ` 
--query "[@].value" 





Com a chave de acesso, precisamos criar um arquivo com as 
credenciais SMB, que serão utilizadas para montar o diretório. Para 
isso, podemos utilizar o seguinte script nas instâncias do conjunto 
de escala: 


# bash 
# Execute esses comandos em todas as instâncias do conjunto de escala 


storageAccountName=="<substituir: nome conta de armazenamento>" 
smbCredentialFile="/etc/smbcredentials/$storageAccountName.cred" 


if [ ! -d "/etc/smbcredentials" |; then 
sudo mkdir "/etc/smbcredentials" 
fi 


if [ ! -f $smbCredentialFile ]; then 
echo "username=$storageAccountName" IN 
sudo tee $smbCredentialFile > /dev/null 
echo \ 


"password=<substituir: chave da conta de armazenamento>" | \ 
sudo tee -a $smbCredentialFile > /dev/null 
else 


echo "Arquivo $smbCredentialFile não foi modificado." 
fi 
sudo chmod 600 $smbCredentialFile 





Para configurar a montagem automática do diretório e dar acesso ao 
usuario da aplicação (www-data), precisamos adicionar uma linha 
no arquivo /etc/fstab das instâncias executando o script: 


# bash 
# Execute esses comandos em todas as instancias do conjunto de escala 


mntPath="/mnt/dataprotection" 
sudo mkdir -p $mntPath 
smbPath= \ 
"//$storageAccountName. file.core.windows.net/dataprotection" 
if [ -z "$(grep $smbPath\ $mntPath /etc/fstab)" ]; then 


echo "$smbPath $mntPath cifs uid=www-data, gid=www- 
data, dir mode=0700,file mode=0600,nofail,vers=3.0,credentials=$smbCred 
entialFile,serverino" À 

| sudo tee -a /etc/fstab > /dev/null 

else 

echo "Arquivo /etc/fstab não foi modificado." 
fi 
sudo mount -a 





Compartilhamento de arquivos das fotos dos produtos 


Quando cadastramos um produto pelo módulo de administração do 
site, sua foto é armazenada no diretório images/products da 
aplicação. Esse diretório precisa ser compartilhado por todos os 
servidores do nosso conjunto de escalas, caso contrário a foto de 
um produto cadastrado em uma instância não será visível nas 
outras. 


Como utilizamos uma única conta de armazenamento para os 
compartilhamentos de proteção de dados e fotos dos produtos, 
podemos usar o mesmo arquivo de credenciais, que criamos no 
passo anterior, para montar o diretório das fotos. Para isso basta 
atualizar o arquivo /etc/fstab com o seguinte script: 


# bash 
# Execute esses comandos em todas as instancias do conjunto de escala 


prodPath="/var/www/eshoponweb/web/wwwroot/images/products” 

prodSmbPath= À 
"//$storageAccountName.file.core.windows.net/products" 

if [ -z "$(grep $prodSmbPath\ $prodPath /etc/fstab)" ]; then 


echo "$prodSmbPath $prodPath cifs uid=www-data, gid=www- 
data, dir_mode=0755, file _mode=0644, nofail, vers=3.0,credentials=$smbCred 
entialFile,serverino" À 

| sudo tee -a /etc/fstab > /dev/null 

else 

echo "Arquivo /etc/fstab nao foi modificado." 
fi 
sudo mount -a 





Execução das aplicações Web e PublicAPI 


Agora que temos os diretórios necessários mapeados, podemos 
subir a aplicação. Para isso, basta requisitar aO systema O início dos 
serviços configurados com os seguintes comandos em todas as 
instâncias: 


# bash 
# Execute esses comandos em todas as instâncias do conjunto de escala 


sudo systemctl start kestrel-api.service 
sudo systemctl start kestrel-web.service 





Após a subida dos serviços, podemos visualizar a saída do console 
das aplicações através do comando journalct1 : 


# bash 
# Execute esses comandos nas instancias do conjunto de escala 


sudo journalctl -fu kestrel-api.service 
sudo journalctl -fu kestrel-web.service 





Configuragao do proxy reverso NGINX 


Após colocarmos os serviços no ar, precisamos disponibiliza-los na 
porta TCP 80 através do servidor de proxy reverso NGINX. A 
aplicação Web será publicada na rota raiz (/) e a PublicAPI na rota 
api (/api). 


Para fazer essa configuração, precisamos substituir o arquivo 
/etc/nginx/sites-available/default em todas as instâncias do conjunto 
de escala com o seguinte conteúdo: 


server { 

listen 80; 

location / { 
proxy_pass http: //localhost: 8000; 
proxy_http_version 1.1; 
proxy set header Upgrade $http upgrade; 
proxy set header Connection keep-alive; 
proxy set header Host $host; 
proxy cache bypass $http upgrade; 
proxy set header X-Forwarded-For $proxy add x forwarded for; 
proxy set header  X-Forwarded-Proto $scheme; 

} 

location /api { 
proxy_pass http://localhost:9000; 
proxy http version 1.1; 
proxy set header Upgrade $http upgrade; 
proxy set header Connection keep-alive; 
proxy set header Host $host; 
proxy cache bypass $http upgrade; 
proxy set header X-Forwarded-For $proxy add x forwarded for; 
proxy set header X-Forwarded-Proto $scheme; 





Após a atualização do arquivo, basta reiniciar o NGINX com o 
comando: 


# bash 


# Execute esse comando em todas as instancias do conjunto de escala 
sudo nginx -s reload 





Balanceador de carga 


Para distribuir as requisições entre um conjunto de servidores, 
normalmente é utilizado um dispositivo de rede conhecido por 
balanceador de carga. Quando criamos um conjunto de escalas no 
Azure, um balanceador é adicionado automaticamente. Por default, 
seu nome é o nome do conjunto com o sufixo LB. 


O balanceador de carga tem uma funcionalidade chamada Health 
Probes, que no portal do Azure foi traduzido como Investigações de 
Integridade. Essa funcionalidade permite que você envie uma 
requisição para as instâncias do conjunto de escalas para verificar 
se estão saudáveis. 


A aplicação eShopOnWeb implementa a funcionalidade Health 
Checks do ASP.NET Core (documentada no artigo Health checks in 
ASPNET Core - https://docs.microsoft.com/aspnet/core/host-and- 
deploy/health-checks) na rota /health, como podemos ver no 
método Microsoft.eShopWeb.Web.Startup.Configure da aplicagao Web. 


public void Configure( 


IApplicationBuilder app, IWebHostEnvironment env) 


app.UseHealthChecks("/health", 
new HealthCheckOptions 
{ 
ResponseWriter = async (context, report) => 
{ 
var result 
{ 
status report.Status.ToString(), 
errors report.Entries.Select(e => new 
{ 
key = e.Key, 
value = Enum.GetName( 
typeof(HealthStatus), e.Value.Status) 


}) 
}.ToJson(); 


context.Response.ContentType = 
MediaTypeNames.Application.Json; 
await context.Response.WriteAsync(result) ; 





Aproveitando que a aplicação implementa essa funcionalidade, 
podemos configurar o balanceador de carga para verificar a 
integridade das instâncias. Execute os seguintes comandos para 
criar o investigador de integridade e configurar uma regra no 
balanceador para utilizá-lo nas instâncias do conjunto de escalas. 


# PowerShell 


$loadbalancer = az network 1b list ` 
-g $resourcegroup ` 
--query "[?contains(name, '$scalesetname')].name" 
ConvertFrom-Json 
az network lb probe create ` 
-g $resourcegroup ` 
-n healtchecks ` 
--lb-name $loadbalancer ` 
--protocol http ` 
--port 80 ` 
--path /health 
az network 1b rule create ` 
-g $resourcegroup ` 
-n lbr-web-ch-001 ` 
--lb-name $loadbalancer ` 
--backend-pool-name "$($scalesetname)LBBEPool" ` 
--backend-port 80 ` 
--frontend-ip-name loadBalancerFrontEnd ` 
--frontend-port 80 ` 
--protocol tcp --probe-name healthchecks 





4.3 Teste da aplicação 


Se tudo correu bem, neste momento a aplicação já está no ar. Para 
testá-la, use o seu navegador de preferência e acesse o endereço 
DNS configurado no capítulo anterior. No exemplo dado, 
configuramos o nome eshoponwebchee1 na região brazilsouth , 
portanto a aplicação estará disponível no endereço 
http://eshoponwebch001.brazilsouth.cloudapp.azure.com. 
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Figura 4.2: Pagina inicial da aplicagao 


4.4 Resumo 


Neste capítulo, mostramos que, com poucas alterações, é possível 
migrar uma aplicação para o Azure utilizando o método Lift & Shift. 
Mesmo sendo relativamente simples, já é possível se beneficiar de 
algumas funcionalidades do novo ambiente em nuvem, como 
escalabilidade automática e plataformas de serviço (no nosso 
exemplo, utilizamos o Azure SQL Database). 


Nessa primeira fase da migração, descrevemos o processo de 
publicação manual. No próximo capítulo, detalharemos como 
automatizar esse processo através de scripts. 


CAPITULO 4 
Publicação da aplicação 


Escrito por Alexandre Teoi e Luis Henrique Demetrio. 


No capítulo anterior, montamos a infraestrutura no Azure que vai 
receber a nossa aplicação. Nesse ambiente, criamos um Virtual 
Machine Scale Set, que nos fornece um número configurável de 
máquinas virtuais onde instalaremos os módulos da aplicação. 


Antes de publicar a aplicação, precisamos adaptá-la para que ela 
possa ser executada no ambiente escalável, que criamos. Feita a 
adaptação, podemos publicá-la executando os seguintes passos em 
cada instância do nosso Virtual Machine Scale Set. Utilize a 
máquina virtual de administração que criamos no capítulo anterior 
para se conectar em cada instância do conjunto de escalas para 
executar estes passos: 


e Instalar o ambiente de execução (runtime) do ASP.NET Core 

3.1. 

Instalar o pacote NGINX. 

e Publicar o módulo Web. 

e Publicar o módulo PublicAPI. 

e Mapear o compartilhamento de arquivos do módulo de proteção 
de dados. 

e Mapear o compartilhamento de arquivos das fotos dos 

produtos. 

Iniciar as aplicações Web e PublicAPI. 

Configurar o NGINX para atuar como proxy reverso das 

aplicações WEB e PublicAPI. 

Configurar o balanceador de carga. 


4.1 Adaptação da aplicação 


Para publicar a aplicação no nosso ambiente em nuvem, devemos 
fazer as seguintes adaptações na versão original: 


e Reconhecer os cabeçalhos HTTP X-Forwarded-For e X- 
Forwarded-Proto enviados pelo servidor de proxy reverso 
NGINX para informar o endereço IP do cliente e protocolo 
(HTTP ou HTTPS) utilizados na requisição original. 

e Armazenar a chave de criptografia do módulo de proteção de 
dados do ASP.NET Core em um diretório compartilhado. 

e Armazenar as fotos dos produtos em um diretório 
compartilhado. 

e Configurar strings de conexão com o banco de dados. 


X-Forwarded-For e X-Forwarded-Proto 


Para que a aplicação tenha acesso ao endereço IP do cliente e 
protocolo utilizados na requisição, precisamos configurar o ASP.NET 
Core para reconhecer os cabeçalhos HTTP X-Forwarded-For e X- 
Forwarded-Proto. Caso contrário, o endereço IP do cliente recebido 
pela aplicação será sempre o do servidor de proxy reverso NGINX. 
Como o NGINX roda no mesmo servidor da aplicação, esse 
endereço será sempre o localhost. A nossa aplicação exemplo não 
utiliza essas informações, mas aplicações reais normalmente 
precisam delas para, por exemplo, implementar controles de 
segurança. 


A alteração para reconhecer esses cabeçalhos deve ser feita no 
método configure da classe startup do projeto Web, por meio da 
chamada do método IApplicationBuilder.UseForwardedHeaders . 


public void Configure( 
IApplicationBuilder app, 
IWebHostEnvironment env) 


app.UseForwardedHeaders (new ForwardedHeadersOptions 


{ 


ForwardedHeaders = ForwardedHeaders.XForwardedFor 


| ForwardedHeaders .XForwardedProto 


}); 


app.UseCookiePolicy(); 
app.UseAuthentication(); 
app.UseAuthorization() ; 





Chave de criptografia 


A chave de criptografia do módulo de proteção de dados do 
ASP.NET Core deve ser compartilhada entre todas as instâncias do 
conjunto de escalas. Para isso, utilizaremos o compartilhamento de 
arquivos na conta de armazenamento do Azure, que criamos no 
capítulo anterior. Na seção Compartilhamento de arquivos do 
módulo de proteção de dados deste capítulo, descrevemos como 
efetuar o mapeamento desse compartilhamento de arquivos nas 
máquinas virtuais. 


Para que a aplicação busque a chave de criptografia nesse diretório 
mapeado, o projeto Web precisa chamar o método 
IApplicationBuilder.PersistKeysToFileSystem NO método 
ConfigureProductionservices da classe startup . Na nossa 
implementação, o caminho do diretório será configurado através da 
seção DataProtectionPath do arquivo de configuração 


appsettings.json. 


public void ConfigureProductionServices( 
IServiceCollection services) 


services .AddDataProtection() 
.PersistKeysToFileSystem(new DirectoryInfo( 
Configuration.GetSection("DataProtectionPath").Value) 
)5 





O script de instalação, que descreveremos adiante, mapeará o 
compartilhamento de arquivo no diretório /mnt/dataprotection . 


Assim, precisamos adicionar a seção DataProtectionPath ao arquivo 
appsettings.Production.json dO projeto Web: 


{ 
"DataProtectionPath": "/mnt/dataprotection", 
"baseUrls": { 
"webBase": "http://localhost:8000/" 


>, 





Fotos dos produtos 


A aplicação armazena as fotos dos produtos no subdiretório 
images/products da aplicação Web. Para que as fotos dos novos 
produtos cadastrados sejam compartilhadas entre todas as 
instâncias do conjunto de escalas, vamos mapear esse diretório no 
compartilhamento de arquivos products criado anteriormente. Na 
seção Compartilhamento de arquivos das fotos dos produtos deste 


capítulo, descrevemos como efetuar o mapeamento desse 
compartilhamento de arquivos nas máquinas virtuais. 


Strings de conexão 


Os projetos Web e PublicAPI precisam acessar o banco de dados. 
As strings de conexão com o banco para o ambiente de produção 
estão armazenadas no arquivo appsettings.Production.json desses 
projetos. Altere as strings de conexão nesses arquivos com as 
informações do banco de dados criado anteriormente. 


"ConnectionStrings": { 
"CatalogConnection": "Server=tcp:<servidor>, 1433; Initial 
Catalog=Microsoft.eShopOnWeb.CatalogDb;Persist Security 
Info=False;User ID=eshopweb; Password=Senh4supersecre+a; 


MultipleActiveResultSets=False;Encrypt=True;TrustServerCertificate=Fal 
se;Connection Timeout=30;", 

"IdentityConnection": "Server=tcp:<servidor>,1433; Initial 
Catalog=Microsoft.eShopOnWeb.Identity;Persist Security Info=False;User 
ID=eshopweb ; Password=Senh4supersecre+a; 


MultipleActiveResultSets=False;Encrypt=True;TrustServerCertificate=Fal 
se;Connection Timeout=30;" 


} 





4.2 Publicagao 


Agora que temos a aplicação adaptada para rodar no ambiente 
criado, podemos iniciar o seu processo de publicação. Lembre-se de 
que esse processo deve ser executado nas instâncias de máquinas 


virtuais do nosso conjunto de escala. Para acessar essas maquinas, 
precisamos utilizar a estagao de administragao como ponte, 
conforme descrito no capitulo anterior. 





Estação de 


Estação Local Administração 


Rede Virtual 


Figura 4.1: Acesso às instâncias de máquinas virtuais. 
Instalação do ASP.NET Core 3.1 


A instalação do ambiente de execução do ASP.NET Core 3.1 em 
servidores Ubuntu é feita através dos comandos: 


# bash 
# Execute esses comandos em todas as instancias do conjunto de escala 


wget https://packages.microsoft.com/config/ubuntu/18.04/packages- 
microsoft-prod.deb -O packages-microsoft-prod.deb 


sudo dpkg -i packages-microsoft-prod.deb 

sudo apt-get update 

sudo apt-get upgrade -y 

sudo apt-get install -y apt-transport-https 
sudo apt-get install -y aspnetcore-runtime-3.1 
sudo apt-get autoremove -y 





Instalação do NGINX 
O servidor de proxy reverso NGINX é instalado com os seguintes 


comandos: 


# bash 
# Execute esses comandos em todas as instancias do conjunto de escala 


sudo apt-get install -y nginx 
sudo service nginx start 





Publicagao do modulo Web 


Para publicar o modulo Web, devemos gerar os arquivos de 
publicação do projeto Web e, para facilitar a transferência para os 
servidores, compactá-los com a ferramenta tar . Para isso, no 
PowerShell Navegue até o diretório C:\Repos\eShopOnWeb\src\Web € 
execute os seguintes comandos. Após gerar o pacote, copie-o para 
a estação de administração com o comando scp. 


# PowerShell 
# Execute esses comandos na estacao de desenvolvimento 


cd C:\Repos\eShopOnwWeb\ src\Web 


dotnet publish -c Release 

tar -czvf C:\temp\web.tar.gz ` 
-C bin/Release/netcoreapp3.1/publish . 

scp C:\temp\web.tar.gz ` 
eshopadmin@vmeshopadmin.brazilsouth.cloudapp.azure.com:~/ 





Com o pacote na estação de administração, podemos copiá-lo para 
as instâncias do conjunto de escalas com o mesmo comando scp. 


# bash 
# Execute esse comando na estacao de administracao 
# Repita para todas as instancias do conjunto de escala 


scp ~/web.tar.gz eshopadmin@10.1.0.4:~/ 





Com o pacote copiado para as instâncias, podemos descompacta-lo 
com os comandos: 


# bash 
# Execute esses comandos em todas as instancias do conjunto de escala 


sudo mkdir -p /var/www/eshoponweb/web 


sudo tar -xzvf ~/web.tar.gz -C /var/www/eshoponweb/web 
sudo chown -R www-data:www-data /var/www/eshoponweb/web 





Para gerenciar a aplicação Web, utilizaremos o gerenciador de 
serviços systemd (https://github.com/systemd/systemd) do Linux, 


como descrito no guia Host ASP.NET Core on Linux with Nginx 
(https://docs.microsoft.com/aspnet/core/host-and-deploy/linux- 
nginx). 


A configuração de um serviço gerenciado pelo systemd é feita 
através de arquivos unit (unit files). Para a aplicação Web, devemos 
criar um arquivo chamado kestrel-web.service no diretório 
/etc/systemd/system em todas as instâncias do conjunto de escalas 
com o seguinte conteúdo: 


[Unit] 
Description=eShopOnWeb Web 


[Service] 

WorkingDirectory=/var/www/eshoponweb/web 
ExecStart=/usr/bin/dotnet /var/www/eshoponweb/web/Web.d11 
Restart=always 

# Reinicia o serviço após 10 segundos caso de falha do processo 
dotnet: 

RestartSec=10 


KillSignal=SIGINT 
SyslogIdentifier=eshoponweb-web 

User=www-data 
Environment=ASPNETCORE_ENVIRONMENT=Production 
Environment=DOTNET_PRINT_TELEMETRY_MESSAGE=false 
Environment=ASPNETCORE_URLS=http://* : 8000 


[Install] 
WantedBy=multi-user.target 





Essa configuração vai executar a aplicação Web instalada no 
diretório /var/www/eshoponweb/web NO contexto do usuário www-data e 
responderá na porta TCP 8000. O usuário www-data é criado pelo 
NGINX. 


Para habilitar o serviço Web, basta utilizar o comando systemct1 : 


# bash 
# Execute esse comando em todas as instancias do conjunto de escala 


sudo systemctl enable kestrel-web.service 





Publicagao da API 


A publicação da API segue os mesmos passos da publicação do 
módulo Web. Para gerar o pacote de publicação, navegue para o 
diretório c:\Repos\eShopOnWeb\ src\PublicApi NO PowerShell e execute 
os comandos: 


# PowerShell 
# Execute esses comandos na estacao de desenvolvimento 


cd C:\Repos\eShopOnWeb\ src\ PublicApi 

dotnet publish -c Release 

tar -czvf C:\temp\api.tar.gz ` 
-C bin/Release/netcoreapp3.1/publish . 

scp C:\temp\web.tar.gz ` 
eshopadmin@vmeshopadmin.brazilsouth.cloudapp.azure.com:~/ 





Após gerar o pacote e copiá-lo para a estação de administração, 
transfira para as instâncias do conjunto de escala: 


# bash 
# Execute esse comando na estacao de administracao 


# Repita para todas as instancias do conjunto de escala 


scp ~/api.tar.gz eshopadmin@10.1.0.4:~/ 





Feita a transferência, o pacote pode ser descompactado com os 
comandos: 


# bash 
# Execute esses comandos em todas as instancias do conjunto de escala 


sudo mkdir -p /var/www/eshoponweb/api 
sudo tar -xzvf ~/api.tar.gz -C /var/www/eshoponweb/api 
sudo chown -R www-data:www-data /var/www/eshoponweb/api 





Utilizaremos o seguinte arquivo unit para configurar a API no 
systemd. Ele deve ter o nome kestrel-api.service e precisa estar no 
diretório /etc/systemd/system de todas as instâncias do conjunto de 
escalas. 


[Unit] 
Description=eShopOnWeb API 


[Service] 
WorkingDirectory=/var/www/eshoponweb/api 
ExecStart=/usr/bin/dotnet /var/www/eshoponweb/api/PublicApi.d1l 
Restart=always 

# Reinicia o serviço após 10 segundos 

# em caso de falha do processo dotnet: 
RestartSec=10 

KillSignal=SIGINT 
SyslogIdentifier=eshoponweb-api 

User=www-data 
Environment=ASPNETCORE_ENVIRONMENT=Production 
Environment=DOTNET_PRINT_TELEMETRY_MESSAGE=false 
Environment=ASPNETCORE_URLS=http://* : 9000 


[Install] 
WantedBy=multi-user.target 





Essa configuração vai executar a API instalada no diretório 
/var/www/eshoponweb/api NO contexto do usuário www-data e 
responderá na porta TCP 9000. 


Para habilitar a API, devemos utilizar o comando systemctl : 


# bash 
# Execute esse comando em todas as instancias do conjunto de escala 


sudo systemctl enable kestrel-api.service 





Compartilhamento de arquivos do modulo de protegao de 
dados 


Para que as instâncias do conjunto de escalas utilizem a mesma 
chave de criptografia, precisamos armazená-la em um diretório 
compartilhado. Para mapear o diretório nas instâncias, usaremos o 
protocolo SMB (Server Message Block) como descrito no guia Use 
Azure Files with Linux, disponível em 
https://docs.microsoft.com/azure/storage/files/storage-how-to-use- 
files-linux. 


Para acessar o compartilhamento de arquivo na conta de 
armazenamento do Azure, precisamos da chave de acesso da conta 
de armazenamento, que criamos anteriormente. Utilize o seguinte 
comando Azure CLI para buscar essa chave: 


# PowerShell 


az storage account keys list ` 


-g $resourcegroup ` 
-n $storageaccountname ` 
--query "[@].value" 





Com a chave de acesso, precisamos criar um arquivo com as 
credenciais SMB, que serão utilizadas para montar o diretório. Para 
isso, podemos utilizar o seguinte script nas instâncias do conjunto 
de escala: 


# bash 
# Execute esses comandos em todas as instâncias do conjunto de escala 


storageAccountName=="<substituir: nome conta de armazenamento>" 
smbCredentialFile="/etc/smbcredentials/$storageAccountName.cred" 


if [ ! -d "/etc/smbcredentials" |; then 
sudo mkdir "/etc/smbcredentials" 
fi 


if [ ! -f $smbCredentialFile ]; then 
echo "username=$storageAccountName" IN 
sudo tee $smbCredentialFile > /dev/null 
echo \ 


"password=<substituir: chave da conta de armazenamento>" | \ 
sudo tee -a $smbCredentialFile > /dev/null 
else 


echo "Arquivo $smbCredentialFile não foi modificado." 
fi 
sudo chmod 600 $smbCredentialFile 





Para configurar a montagem automática do diretório e dar acesso ao 
usuario da aplicação (www-data), precisamos adicionar uma linha 
no arquivo /etc/fstab das instâncias executando o script: 


# bash 
# Execute esses comandos em todas as instancias do conjunto de escala 


mntPath="/mnt/dataprotection" 
sudo mkdir -p $mntPath 
smbPath= \ 
"//$storageAccountName. file.core.windows.net/dataprotection" 
if [ -z "$(grep $smbPath\ $mntPath /etc/fstab)" ]; then 


echo "$smbPath $mntPath cifs uid=www-data, gid=www- 
data, dir mode=0700,file mode=0600,nofail,vers=3.0,credentials=$smbCred 
entialFile,serverino" À 

| sudo tee -a /etc/fstab > /dev/null 

else 

echo "Arquivo /etc/fstab não foi modificado." 
fi 
sudo mount -a 





Compartilhamento de arquivos das fotos dos produtos 


Quando cadastramos um produto pelo módulo de administração do 
site, sua foto é armazenada no diretório images/products da 
aplicação. Esse diretório precisa ser compartilhado por todos os 
servidores do nosso conjunto de escalas, caso contrário a foto de 
um produto cadastrado em uma instância não será visível nas 
outras. 


Como utilizamos uma única conta de armazenamento para os 
compartilhamentos de proteção de dados e fotos dos produtos, 
podemos usar o mesmo arquivo de credenciais, que criamos no 
passo anterior, para montar o diretório das fotos. Para isso basta 
atualizar o arquivo /etc/fstab com o seguinte script: 


# bash 
# Execute esses comandos em todas as instancias do conjunto de escala 


prodPath="/var/www/eshoponweb/web/wwwroot/images/products” 

prodSmbPath= À 
"//$storageAccountName.file.core.windows.net/products" 

if [ -z "$(grep $prodSmbPath\ $prodPath /etc/fstab)" ]; then 


echo "$prodSmbPath $prodPath cifs uid=www-data, gid=www- 
data, dir_mode=0755, file _mode=0644, nofail, vers=3.0,credentials=$smbCred 
entialFile,serverino" À 

| sudo tee -a /etc/fstab > /dev/null 

else 

echo "Arquivo /etc/fstab nao foi modificado." 
fi 
sudo mount -a 





Execução das aplicações Web e PublicAPI 


Agora que temos os diretórios necessários mapeados, podemos 
subir a aplicação. Para isso, basta requisitar aO systema O início dos 
serviços configurados com os seguintes comandos em todas as 
instâncias: 


# bash 
# Execute esses comandos em todas as instâncias do conjunto de escala 


sudo systemctl start kestrel-api.service 
sudo systemctl start kestrel-web.service 





Após a subida dos serviços, podemos visualizar a saída do console 
das aplicações através do comando journalct1 : 


# bash 
# Execute esses comandos nas instancias do conjunto de escala 


sudo journalctl -fu kestrel-api.service 
sudo journalctl -fu kestrel-web.service 





Configuragao do proxy reverso NGINX 


Após colocarmos os serviços no ar, precisamos disponibiliza-los na 
porta TCP 80 através do servidor de proxy reverso NGINX. A 
aplicação Web será publicada na rota raiz (/) e a PublicAPI na rota 
api (/api). 


Para fazer essa configuração, precisamos substituir o arquivo 
/etc/nginx/sites-available/default em todas as instâncias do conjunto 
de escala com o seguinte conteúdo: 


server { 

listen 80; 

location / { 
proxy_pass http: //localhost: 8000; 
proxy_http_version 1.1; 
proxy set header Upgrade $http upgrade; 
proxy set header Connection keep-alive; 
proxy set header Host $host; 
proxy cache bypass $http upgrade; 
proxy set header X-Forwarded-For $proxy add x forwarded for; 
proxy set header  X-Forwarded-Proto $scheme; 

} 

location /api { 
proxy_pass http://localhost:9000; 
proxy http version 1.1; 
proxy set header Upgrade $http upgrade; 
proxy set header Connection keep-alive; 
proxy set header Host $host; 
proxy cache bypass $http upgrade; 
proxy set header X-Forwarded-For $proxy add x forwarded for; 
proxy set header X-Forwarded-Proto $scheme; 





Após a atualização do arquivo, basta reiniciar o NGINX com o 
comando: 


# bash 


# Execute esse comando em todas as instancias do conjunto de escala 
sudo nginx -s reload 





Balanceador de carga 


Para distribuir as requisições entre um conjunto de servidores, 
normalmente é utilizado um dispositivo de rede conhecido por 
balanceador de carga. Quando criamos um conjunto de escalas no 
Azure, um balanceador é adicionado automaticamente. Por default, 
seu nome é o nome do conjunto com o sufixo LB. 


O balanceador de carga tem uma funcionalidade chamada Health 
Probes, que no portal do Azure foi traduzido como Investigações de 
Integridade. Essa funcionalidade permite que você envie uma 
requisição para as instâncias do conjunto de escalas para verificar 
se estão saudáveis. 


A aplicação eShopOnWeb implementa a funcionalidade Health 
Checks do ASP.NET Core (documentada no artigo Health checks in 
ASPNET Core - https://docs.microsoft.com/aspnet/core/host-and- 
deploy/health-checks) na rota /health, como podemos ver no 
método Microsoft.eShopWeb.Web.Startup.Configure da aplicagao Web. 


public void Configure( 


IApplicationBuilder app, IWebHostEnvironment env) 


app.UseHealthChecks("/health", 
new HealthCheckOptions 
{ 
ResponseWriter = async (context, report) => 
{ 
var result 
{ 
status report.Status.ToString(), 
errors report.Entries.Select(e => new 
{ 
key = e.Key, 
value = Enum.GetName( 
typeof(HealthStatus), e.Value.Status) 


}) 
}.ToJson(); 


context.Response.ContentType = 
MediaTypeNames.Application.Json; 
await context.Response.WriteAsync(result) ; 





Aproveitando que a aplicação implementa essa funcionalidade, 
podemos configurar o balanceador de carga para verificar a 
integridade das instâncias. Execute os seguintes comandos para 
criar o investigador de integridade e configurar uma regra no 
balanceador para utilizá-lo nas instâncias do conjunto de escalas. 


# PowerShell 


$loadbalancer = az network 1b list ` 
-g $resourcegroup ` 
--query "[?contains(name, '$scalesetname')].name" 
ConvertFrom-Json 
az network lb probe create ` 
-g $resourcegroup ` 
-n healtchecks ` 
--lb-name $loadbalancer ` 
--protocol http ` 
--port 80 ` 
--path /health 
az network 1b rule create ` 
-g $resourcegroup ` 
-n lbr-web-ch-001 ` 
--lb-name $loadbalancer ` 
--backend-pool-name "$($scalesetname)LBBEPool" ` 
--backend-port 80 ` 
--frontend-ip-name loadBalancerFrontEnd ` 
--frontend-port 80 ` 
--protocol tcp --probe-name healthchecks 





4.3 Teste da aplicação 


Se tudo correu bem, neste momento a aplicação já está no ar. Para 
testá-la, use o seu navegador de preferência e acesse o endereço 
DNS configurado no capítulo anterior. No exemplo dado, 
configuramos o nome eshoponwebchee1 na região brazilsouth , 
portanto a aplicação estará disponível no endereço 
http://eshoponwebch001.brazilsouth.cloudapp.azure.com. 
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Figura 4.2: Pagina inicial da aplicagao 


4.4 Resumo 


Neste capítulo, mostramos que, com poucas alterações, é possível 
migrar uma aplicação para o Azure utilizando o método Lift & Shift. 
Mesmo sendo relativamente simples, já é possível se beneficiar de 
algumas funcionalidades do novo ambiente em nuvem, como 
escalabilidade automática e plataformas de serviço (no nosso 
exemplo, utilizamos o Azure SQL Database). 


Nessa primeira fase da migração, descrevemos o processo de 
publicação manual. No próximo capítulo, detalharemos como 
automatizar esse processo através de scripts. 


CAPITULO 6 
Gerenciamento de codigo-fonte 


Escrito por Leandro Prado e Augusto Araujo. 


CENARIO 


O time de desenvolvimento está trabalhando na modernização 
da aplicação que será entregue no final da sprint corrente. 
Porém, existem outros trabalhos sendo executados em paralelo, 
como a correção de um bug que está ocorrendo em produção. 


Atualmente o código-fonte do eShopOnWeb não tem nenhum 
controle de versão, o que dificulta o trabalho do time de 
desenvolvimento, porque muitas vezes o código se perde 
durante o processo de codificação. 


Neste capítulo, vamos abordar os seguintes assuntos: 


e Sistemas de controle de versão. 

e O que é Git? 

e Como trabalhar com branch e merge. 
e Pull Request. 

e GitHub Actions. 





6.1 Sistemas de controle de versao 


O sistema de controle de versão tem o objetivo de manter o código- 
fonte seguro, sem o risco de o desenvolvedor perder alguma 
alteração que ocasione algum tipo de erro dentro da aplicação ou 
perda de funcionalidade. 


Existem dois tipos de sistemas de controle de versão: 


e Sistema de controle de versão centralizado. 
e Sistema de controle de versão distribuído. 


Sistema de controle de versão centralizado 


Como sistemas de controle de versão centralizado temos, por 
exemplo, o TFVC e o SVN. Como características, podemos citar: 


e Os históricos são mantidos no servidor, portanto, caso 
necessite consultá-los, é necessário se conectar ao servidor 
para conseguir visualizar. 

e Branches são cópias de arquivos criadas nos servidores, 
ocupando um grande espaço de armazenamento dado que o 
código fica replicado. 

e As permissões podem ser aplicadas em nivel de arquivos. 


Sistema de controle de versão distribuído 


Como sistemas de controle de versão distribuídos temos, por 
exemplo, os repositórios Git. Suas características são um pouco 
diferentes do anterior: 


e Os repositórios inteiros podem ser clonados para a máquina de 
um desenvolvedor local. 

e A clonagem inclui o histórico, ou seja, todo o histórico esta na 
máquina local, tornando sua pesquisa mais rápida. 

e As branches não são cópias de arquivos e sim ponteiros que 
apontam para alterações dentro do repositório, o que os deixa 
mais leves. 


Nos próximos tópicos e capítulos, vamos trabalhar com nossa 
aplicação inteiramente versionada em um repositório no GitHub, 
então destinamos este capítulo para mostrar um pouco mais dos 
conceitos de Git e como trabalhar com sistemas de controle de 
versão distribuídos. 


6.2 O que é Git? 


O Git foi criado em 2005 pelo criador do kernel do Linux, Linus 
Torvalds, depois que a parceria com a empresa proprietaria 
Bitkeeper se rompeu, pois a ferramenta passou a ser paga. A 
comunidade que desenvolvia o Linux começou a desenvolver a sua 
própria ferramenta baseada em lições aprendidas ao usar o 
BitKeeper. Foi nesse momento que surgiu o Git com as seguintes 
metas: 


e Velocidade. 

e Projeto simples. 

e Forte suporte para desenvolvimento não linear (milhares de 
branches). 

e Completamente distribuído. 

e Capaz de lidar com projetos grandes com eficiência. 


Git é um sistema de controle de versão (do inglês, Source Code 
Management) distribuído. Cada desenvolvedor tem uma cópia do 
repositório de origem em sua máquina, por isso ele é chamado de 
distribuído. Os desenvolvedores podem executar um commit em um 
conjunto de alterações em sua máquina de desenvolvimento e 
executar operações de controle de versão como histórico e 
comparação, sem a necessidade de uma conexão externa. 
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Figura 6.1: Sistema de controle distribuído. 


O mais importante para se aprender ao utilizar o Git sao os trés 
estágios que os nossos arquivos podem possuir, sendo eles: 


e Modified: significa que você alterou um ou mais arquivos, mas 
ainda não confirmou em seu repositório local. 

e Staged: significa que você marcou um ou mais arquivos 
modificados para criar um snapshot. 

e Committed: significa que seus arquivos foram salvos em seu 
repositório local. 


Diferentemente de outros gerenciadores de código-fonte que 
trabalham com as diferenças (diff) das alterações em cada arquivo, 
o Git utiliza um snapshot, ou seja, quando uma alteração é realizada 
no repositório, o Git tira uma foto do estado de todos os arquivos e 
diretórios e salva em uma estrutura interna de árvore na qual os 
snapshots possuem links entre si. 





Diretório Trabalho Área de Staging Repositório Local (.git) 





Figura 6.2: Os três estágios do Git. 
O workflow básico da utilização do Git é: 


1. Você modifica os arquivos no repositório local (Working Tree). 
2. Você seleciona quais arquivos deverão fazer parte do seu 
próximo commit. Essa informação ficará armazenada na área 


de Staging. 

3. Você salva suas modificações ( git commit ). Isso faz com que os 
arquivos, que estão na área de Staging, criem um snapshot em 
seu repositório local. 


Qual a diferença entre Git e GitHub? 


GitHub é uma plataforma para auxiliar os times de desenvolvimento 
com hospedagem do código-fonte baseado no Git de forma gratuita. 
O GitHub também é a plataforma onde a maioria dos projetos open 
source são hospedados, como Microsoft Visual Studio Code, 
Kubernetes, Red Hat OpenShift, Ansible etc. Além disso, é uma 
enorme rede onde desenvolvedores e desenvolvedoras podem se 
conectar. 


6.3 Como iniciar a utilização do Git? 


Para iniciar a utilização do Git, primeiramente temos que fazer seu 
download e a instalação em nossa máquina. Para baixá-lo, acesse a 
URL a seguir e selecione a versão do seu sistema operacional. 
Pode seguir com a instalação padrão. 


https://git-scm.com/downloads 


Existem varias maneiras de interagir com o Git, sendo que a mais 
utilizada pelos desenvolvedores é a própria console do sistema 
operacional, mas também é possível utilizar uma ferramenta gráfica 
(GUI - Graphical User Interface). 


NOTA 


Você também pode utilizar uma interface para interagir com o 


Git, como o Visual Studio, Visual Studio Code ou outra 
ferramenta listada neste link https://git-scm.com/downloads/guis. 





A seguir, listamos os comandos basicos para trabalhar com o Git: 


e git init: inicializa um novo repositório na maquina local. 

e git clone: baixa um repositorio ja existente. 

e git add: prepara todos os arquivos alterados na area de 
commit. 

e git commit: aplica as alterações realizadas nos arquivos no 
repositorio local. 

e git push: envia todas as alterações do repositório local para o 
repositório remoto. 

e git pull: atualiza o repositório local com as alterações do 
repositório remoto. 

e git fetch: realiza o download dos objetos e referências do 
repositório. 

e git status: disponibiliza o status do repositório local. 

e git log: exibe o histórico de alterações do repositório local. 


Agora que já sabemos os comandos básicos, estamos prontos para 
colocar o eShopOnWeb no Git. O primeiro passo é criar um 
repositório local utilizando o comando git init dentro do diretório 
onde se encontra a aplicação. 


# Git Bash 


C:\Repos\eShopOnWeb> git init 





Após a execução desse comando, podemos perceber que foi criada 
uma pasta chamada .git conforme a seguinte figura. Esse é um 
diretório especial utilizado pelo próprio Git que tem a finalidade de 
gerenciar todas as versões de todos os arquivos do nosso 
repositório. O arquivo HEAD também é muito importante, pois ele 
aponta para a branch ativa na qual estamos trabalhando. 
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Figura 6.3: Pasta .git 


Uma boa prática é criar um arquivo chamado .gitignore que serve 
para ignorar alguns arquivos ou diretórios não necessários, 
deixando nosso repositório limpo. Veja o comando a seguir para 
criar esse arquivo em nosso repositório. 


# Git Bash 


C:\Repos\eShopOnWeb> fsutil file createnew .gitignore @ 





Nosso projeto é desenvolvido em .NET e estamos utilizando a IDE 
Visual Studio. Por esse motivo, devemos ignorar alguns arquivos e 
diretórios temporários que o Visual Studio gera. Abra o arquivo 
.gitignore Criado e adicione o conteúdo conforme o exemplo: 
https://github.com/github/gitignore/blob/master/VisualStudio.gitignore 


Abaixo podemos ver parte do arquivo .gitignore . 


3 -gitignore - Notepad 

File Edit Format View Help 

## Ignore Visual Studio temporary files, build results, and 

## files generated by popular Visual Studio add-ons. 

Ht 

## Get latest from https://github.com/github/gitignore/blob/master/VisualStudio.gitignore 


# User-specific files 
*.rsuser 
*. suo 
* user 
*.userosscache 
*.sln.docstates 


# User-specific files (MonoDevelop/Xamarin Studio) 
*.userprefs 


# Mono auto generated files 
mono crash.* 


& Build results 
[Dd]ebug/ 
[Dd]ebugPublic/ 
[Rr]Jelease/ 
[Rr]Jeleases/ 
x64/ 

x86/ 

[Ww] [Ii] [Nn]32/ 
[Aa] [Rr] [Mm] / 
[Aa] [Rr] [Mm]64/ 
bld/ 

[Bb]in/ 

[00 ]bj/ 

[L1]og/ 
[Ll]ogs/ 


Figura 6.4: Conteudo do arquivo .gitignore 


NOTA 


Neste repositório são disponibilizados outros exemplos de 
arquivos .gitignore : https://github.com/github/gitignore. 





Para validar o estado em que o nosso repositório se encontra, 
podemos executar o comando git status. 


PS C:\Repos\eShopOnWeb> git status 
On branch master 


No commits yet 


Untracked files: 
(use "git add <file>..." to include in what will be committed) 


nothing added to commit but untracked files present (use "git add" to track) 
PS C:\Repos\eShopOnWeb> 





Figura 6.5: Comando Git Status. 


Como podemos ver, nossos arquivos ainda estao pendentes para 
serem rastreados pelo Git, por isso devemos executar o comando 
git add . para adiciona-los a area de Staging e marca-los para 
serem inclusos no proximo commit. 


# Git Bash 
C:\Repos\eShopOnWeb> git add . 





Neste momento, podemos executar o comando git status 
novamente para validar o estado atual do nosso repositório local. 
Devemos obter um resultado conforme a seguinte figura. 


# Git Bash 


C:\Repos\eShopOnWeb> git status 





PS C:\Repos\eShopOnWeb> git status 
On branch master 


No commits yet 


Changes to be committed: 
(use "git rm --cached <file>..." to unstage) 
fil .gitignore 


e b 





Figura 6.6: Resultado do comando Git Status. 


O próximo passo é salvar e criar o snapshot dos arquivos em nosso 
repositório local. Para isso, precisamos executar o comando git 
commit . 


# Git Bash 


C:\Repos\eShopOnWeb\> git commit -m “initial commit" 





PS C:\Repos\eShopOnWeb> git commit 

[master (root-commit) ba9859a] initial commit 

377 files changed, 19452 insertions(+) 

create mode 100644 .gitignore 

create mode 100644 LICENSE 

create mode 100644 README.md 

create mode 100644 eShopOnWeb.sln 

create mode 100644 src/AppLicationCore/AppLicationCore.csproj 

create mode 100644 src/ApplicationCore/CatalogSettings.cs 

create mode 100644 src/AppLicationCore/Constants/AuthorizationConstants.cs 

create mode 100644 src/ApplicationCore/Entities/BaseEntity.cs 

create mode 100644 src/ApplicationCore/Entities/BasketAggrepate/Basket.cs 

create mode 100644 src/AppLicationCore/Entities/BasketAggregate/BasketItem.cs 
create mode 100644 src/AppLicationCore/Entities/BuyerAggregate/Buyer.cs 

create mode 100644 src/AppLlicationCore/Entities/BuyerAggregate/PaymentMethod.cs 
create mode 100644 src/ApplicationCore/Entities/CatalogBrand.cs 

create mode 100644 src/ApplicationCore/Entities/CatalogItem.cs 

create mode 100644 src/ApplicationCore/Entities/CatalogType.cs 

create mode 1006414 src/AppLlicationCore/Entities/OrderAggregate/Address.cs 

create mode 100644 src/AppLicationCore/Entities/OrderAggregate/CataLogItemOrdered.cs 
create mode 100644 src/AppLicationCore/Entities/OrderAggregate/Order.cs 

create mode 100644 src/AppLicationCore/Entities/OrderAggregate/OrderItem.cs 

create mode 1006414 src/ApplicationCore/Exceptions/BasketNotFoundException.cs 

create mode 100644 src/ApplicationCore/Exceptions/DuplicateCatalogItemNameException.cs 
create mode 100644 src/AppLicationCore/Exceptions/EmptyBasketOnCheckoutException.cs 
create mode 100644 src/ApplLicationCore/Exceptions/GuardExtensions.cs 

create mode 100644 src/AppLicationCore/Extensions/JsonExtensions.cs 





Figura 6.7: Resultado do comando Git Commit. 


Agora que você já possui um commit inicial, podemos executar o 
comando git 1og para visualizar todo o histórico de alterações 
realizadas no repositório local. Na seguinte figura, temos um 
exemplo desse comando. 


PS C:\Repos\eShopOnWeb> git Log 

commit 5212d320637bd29098fbc2cb61ef32a8a6cid9f9 ( 

Author: Leandro Silveira Prado <leandro.pradofoutlook.com.br> 
Date: Tue Oct 13 21:03:39 2020 -0300 


initial commit 
PS C:\Repos\eShopOnwWeb> 





Figura 6.8: Resultado do comando Git Log. 


Perceba que no log temos uma sequência de caracteres, que é um 
hash chamado SHA-1. Esta é uma sequência de 40 caracteres 
composta de caracteres hexadecimais (0-9 e-f) e é calculada com 


base no conteúdo de uma estrutura de arquivo ou diretório no Git. 
Esse hash trabalha como um checksum para garantir a integridade 
dos arquivos e dos diretórios do repositório Git, dessa forma fica 
praticamente impossível alterar algum arquivo ou algum diretório 
sem que o Git saiba. 


6.4 Enviando seu código para o GitHub 


Neste momento do projeto, o código-fonte da aplicação está 
somente no repositório local, porém precisamos compartilhá-lo com 
outros membros do time. Uma das maneiras de fazer isso é utilizar o 
GitHub. 


NOTA 


Outra ferramenta para realizar todo o processo de 


gerenciamento do projeto é o Azure DevOps. Para mais 
informações, veja esse link: 
https://azure.microsoft.com/services/devops/ 





Atualmente, o GitHub oferece um conjunto de funcionalidades para 
desenvolvedores, como: 


e Hospedagem de código-fonte e documentação utilizando Git. 
e Processo de CI/CD utilizando o GitHub Actions. 

e Segurança no desenvolvimento. 

e Code Review. 

e Gerenciamento de projetos e dos times de desenvolvimento. 


Para criar uma conta no GitHub, basta acessar o link 
https://github.com e criar um usuário. 


Após a criação da conta no GitHub, vamos criar um repositório Git 
onde vamos compartilhar todo o código-fonte da aplicação. Na tela 


inicial do GitHub, selecione a opção Start New Repository e adicione 
o nome do repositório. Para este livro, vamos utilizar o nome 
eShopOnWeb. 

NOTA 


O GitHub fornece duas opções para criar um repositório: 


Private: são repositórios acessíveis apenas por pessoas 
autorizadas. 


Public: são repositórios abertos, acessíveis pela internet e que 
podem ser acessados por qualquer pessoa. Geralmente são 
utilizados por projetos open source para os quais qualquer 
pessoa desenvolvedora pode contribuir. 





Create a new repository 
A repository contains all project files, including the revision history. Already have a project repository elsewhere? 
Import a repository. 


Owner * Repository name * 
EJ CEProjectFalcon= | eShopOnWeb ZA 


Great repository names are short and memorable. Need inspiration? How about turbo-couscous? 


Description (optional) 


1 Public 


Ga Anyone on the internet can see this repository. You choose who can commit. 
J H EA 


O O Private 
LJ You choose who can see and commit to this repository. 


Initialize this repository with: 
Skip this step if you're importing an existing repository. 


O Add a README file 


This is where you can write a long description for your project. Learn more. 


O Add .gitignore 


Choose which files not to track from a list of templates. Learn more. 


O Choose a license 
A license tells others what they can and can't do with your code. Learn more. 


Create repository 


Figura 6.9: Criação do repositório. 


Quando finalizamos a criação do repositório, a interface do GitHub 
fornece algumas informações importantes de como devemos 
configurar nosso repositório local para interagir com o repositório 
remoto. Uma das configurações que devemos realizar é atualizar a 
URL do repositório remoto, pois ela é necessária para o Git 
entender para qual repositório remoto deve enviar as alterações. 
Para isso, utilizamos o comando git remote : 


# Git Bash 


C:\Repos\eShopOnWeb> git remote add origin ` 
https://github.com/CEProjectFalcon/eShopOnWeb. git 





Para você verificar qual repositório remoto esta sendo utilizado, 
podemos executar o comando git remote. 


PS C:\Repos\eShopOnWeb> git remote 

origin https://github.com/CEProjectFalcon/eShopOnWeb.git (fetch) 
origin https://github.com/CEProjectFalcon/eShopOnWeb.git (push) 
PS C:\Repos\eShopOnWeb> | l 





Figura 6.10: Resultado do comando Git Remote 


Agora nosso repositório local está preparado para ser enviado para 
o repositório remoto. O comando que devemos utilizar é O git push 
e o resultado da execução pode ser visualizado na figura a seguir. 


# Git Bash 
C:\Repos\eShopOnWeb> git push -u origin master 


PS C:\Repos\eShopOnWeb> git push origin master 
Enumerating objects: 469, done. 
Counting objects: 100% (469/469), done. 
Delta compression using up to 8 threads 
Compressing objects: 100% (451/451), done. 
Writing objects: 100% (469/469), 3.11 MiB | 215.00 KiB/s, done. 
Total 469 (delta 97), reused 60 (delta 0), pack-reused 0 
remote: Resolving deltas: 100% (97/97), done. 
To https://github.com/CEProjectFalcon/eShopOnWeb.git 
* [new branch] master -> master 
Branch 'master' set up to track remote branch 'master' from 'origin'. 
PS C:\Repos\eShopOnweb> | 





Figura 6.11: Resultado do comando Git Push 


Nessa fase, todo o código-fonte do nosso projeto foi enviado para o 
GitHub e os outros membros do time estão aptos para utilizar o 
mesmo código para efetuar a codificação. Veja na seguinte figura 
que o commit realizado localmente foi enviado para o repositório 
remoto hospedado no GitHub. 





<> Code Issues Pull requests Actions Projects Security Insights Settings 
E master ~ F 1branch © Otags Go to file Add file ~ About B 
No description, website, or 
6 Isprado initial commit 5212032 6daysago {1 commits topics provided. 
Readme 
Bm src initial commit 6 days ago HU ee 
MIT License 
D .gitignore initial commit 6 days ago e e 
[3 LICENSE initial commit 
Releases 
D READMEmMA initial commit 6 days ago 
No releases published 
[3 eshopOnweb.sln initial commit 6 days ago 


Create a new release 


Figura 6.12: Repositório remoto no GitHub 


Agora você deve estar se perguntando: como outro membro do meu 
time pode baixar esse código para sua estação de 
desenvolvimento? A resposta é: utilizando o comando git clone. 
Esse comando baixa toda a estrutura do repositório remoto para o 
repositório local. 


# Git Bash 
C:\Repos\eShopOnWeb> git clone ` 


https://github.com/CEProjectFalcon/eShopOnWeb. git 





6.5 Estratégia de branch/merge 


Um dos pontos importantes no processo de desenvolvimento é a 
política de branch e merge. Essa política vai definir como o time vai 


trabalhar nas demandas em paralelo sem interferir no trabalho dos 
outros membros do time. 
NOTA 


Atualmente a comunidade possui varios workflows de branch e 
merge, sendo as mais conhecidas: 


GitFlow https://nvie.com/posts/a-successful-git-branching-model/ 


GitHub Flow https://guides.github.com/introduction/flow/ 





Uma branch é uma ramificação que habilita que os desenvolvedores 
trabalhem de forma paralela sem nenhuma interferência uma na 
outra. Na seguinte figura, podemos ter uma visão simplificada de 
como as branches funcionam no Git. 


Feature-02 Feature-01 master 





© 
IU 
© 


Figura 6.13: Funcionamento de branches no Git. 


Quando criamos um novo repositório no Git, automaticamente é 
criada a branch master . Essa é a branch default do Git. 








Figura 6.14: Detalhe da árvore de alterações. 


NOTA 


No momento que esse livro é escrito, o GitHub está mudando a 
nomenclatura de master para main. 


Para maiores detalhes, veja a documentação do GitHub no link 
https://github.com/github/renaming. 





Mas como o Git sabe em qual branch estou trabalhando? 


O Git possui um ponteiro interno chamado Heap, representado por 
um arquivo chamado HEAD que fica dentro da pasta .git . Dentro 
desse arquivo, nós vamos encontrar uma referência simbólica para 
a branch corrente em que estamos trabalhando. Se você o abrir, 
teremos um conteúdo parecido com a seguinte figura. 


E HEAD - Notepad 
File Edit Format View Help 
ref: refs/heads/master 


Figura 6.15: Conteúdo do arquivo HEAD. 


O Git é simples de usar e isso pode ser percebido quando vamos 
criar branches usando o comando git branch [nome da branch]. No 
exemplo a seguir, estamos executando o comando para criar duas 
branches e a seguinte figura demonstra como a árvore do Git 
deverá ficar. 


# Git Bash 


C:\Repos\eShopOnWeb> git branch features/feature-01 
C:\Repos\eShopOnWeb> git branch features/feature-02 














Figura 6.16: Detalhes da arvore com duas branches. 


Neste momento, as duas branches apontam para o mesmo commit, 
ou seja, as duas branches possuem as mesmas versões de 
arquivos. Para visualizar todas as branches que você possui em seu 
repositório local, podemos executar o comando git branch. 


# Git Bash 
C:\Repos\eShopOnWeb> git branch 


PS C:\Repos\eShopOnWeb> git branch 
features/feature-@1 
features/feature-02 





Figura 6.17: Resultado do comando Git branch. 


Na imagem anterior, podemos perceber que temos um caractere * 
na branch master , O que significa que o contexto atual em que 
estamos trabalhando é a master. 


Para iniciar qualquer alteração, primeiramente devemos alterar o 
contexto para a branch em questão. Para isso, devemos executar o 
comando git checkout [nome da branch]. 


# Git Bash 
C:\Repos\eShopOnWeb> git checkout features/feature-01 


PS C:\Repos\eShopOnWeb> git checkout features/feature-01 
Switched to branch 'features/feature-01' 
PS C:\Repos\eShopOnWeb> git branch 


* 


features/feature-02 
master 





Figura 6.18: Resultado do comando Git Checkout. 


Perceba que o * mudou de lugar e agora está apontando para 
features/feature-91 , O que significa que neste momento todas as 
alterações nos arquivos desse repositório serão executadas nessa 
branch corrente. Na seguinte figura, podemos perceber que a HEAD 
está apontando para a branch Feature-01. 









Figura 6.19: Detalhes da arvore com a HEAD. 


Agora que estamos no contexto da branch Feature-01, podemos 
fazer uma alteração no código-fonte para criar um commit. Para fins 
didáticos, vamos apenas adicionar um summary acima do método 
PublicApi\CatalogItemEndpoints\Create.cs . 


/// <summary> 

/// Create 

/// </summary> 

/// <param name="itemRepository"></param> 
/// <param name="uriComposer"></param> 
/// <param name="webFileSystem"></param> 


public Create(IAsyncRepository<CatalogItem> itemRepository, 


IUriComposer uriComposer, 
FileSystem webFileSystem) 


_itemRepository = itemRepository; 
_uriComposer = uriComposer; 
_webFileSystem = webFileSystem; 





Voltando para o console, podemos executar o comando git status e 
ver que o Git identificou que alteramos um arquivo. 


# Git Bash 
C:\Repos\eShopOnWeb> git status 


PS C:\Repos\eShopOnWeb> git status 
On branch features/feature-01 
Changes not staged for commit: 
(use "git add <file>..." to update what will be committed) 
(use "git restore <file>..." to discard changes in working directory) 





Figura 6.20: Resultado do comando Git Status. 
Para efetivar essa alteração, temos que executar duas ações: 


1. git add . : adiciona todos os arquivos que foram alterados na 
área de staging do Git. 
2. git commit : efetiva a alteração e salva o arquivo na base do Git. 


# Git Bash 
C:\Repos\eShopOnWeb> git add . 
C:\Repos\eShopOnWeb> git commit -m “adicionado o summary" 


PS C:\Repos\eShopOnWeb> git add 

PS C:\Repos\eShopOnWeb> git commit 
[features/feature-01 e820963] adicionado o summary 
1 file changed, 6 insertions(+) 





Figura 6.21: Resultado do comando git commit. 


A cada alteração (commit) realizada no repositório, é adicionado um 
novo ramo à árvore de alterações e o ponteiro Heap é alterado para 
esse novo ramo. Veja com mais detalhes como ficou a árvore na 
seguinte figura. 







Commit 3 






Figura 6.22: Detalhes da árvore com a nova branch. 


Quando todo o desenvolvimento da Feature-01 for finalizado, 
podemos fazer o merge dos arquivos com a branch master, que é a 
branch principal. O procedimento de merge vai identificar todos os 
arquivos que foram alterados na branch Feature-01 e vai mesclar 
com os arquivos da branch master. Para realizar essa operação, 
primeiro temos que mover o contexto para a master e depois 
executar o comando git merge. 


# Git Bash 
C:\Repos\eShopOnWeb> git checkout master 
C:\Repos\eShopOnWeb> git merge features/feature-01 


PS C:\Repos\eShopOnWeb> git checkout master 


Switched to branch 'master' 
Your branch is up to date with 'origin/master'. 
PS C:\Repos\eShopOnWeb> git merge features/feature-01 
Updating 5212d32. .e820963 
Fast-forward 
src/Publicapi/CatalogItemEndpoints/Create.cs | 6 
1 file changed, 6 insertions(+) 





Figura 6.23: Resultado do comando Git Checkout. 


Como todas as alterações que realizamos na branch Feature-01 
estão na branch master, podemos deletar a branch Feature-01, pois 
não vamos mais utilizá-la e deixar nosso repositório limpo. 


# Git Bash 
C:\Repos\eShopOnWeb> git branch 


C:\Repos\eShopOnWeb> git branch -d features/feature-01 
C:\Repos\eShopOnWeb> git branch 





PS C:\Repos\eShopOnWeb> git branch 
features/feature-01 


features/feature-02 
* 


PS C:\Repos\eShopOnWeb> git branch features/feature-01 
Deleted branch features/feature-01 (was e820963). 
PS C:\Repos\eShopOnWeb> git branch 

features/feature-02 





Figura 6.24: Resultado do comando Git branch. 


Neste momento, a branch master possui todas as alterações que 
fizemos na branch Feature-01. Na seguinte figura, podemos ver 
como ficou o ponteiro do Git após o merge e após a deleção da 
branch feature-01. 









Figura 6.25: Detalhes da árvore com a nova HEAD. 


6.6 Pull Request 


O Pull Request (PR) é o coração do GitHub, é o meio pelo qual os 
membros do time podem colaborar com a qualidade do código. Eles 
permitem que você informe aos outros membros do time sobre as 
alterações que você enviou para uma branch. Uma vez que um pull 
request é aberto, você pode discutir e revisar as mudanças com 
outros membros do time, garantindo a qualidade do código. Quando 
estiver satisfeito com as alterações propostas, você pode realizar o 
merge do seu pull request com a branch de destino. 


Para exemplificar a utilização do pull request, vamos alterar a 
branch features/feature-02 criada anteriormente. Vamos mudar o 
contexto para a branch feature-02 executando o comando git 


checkout [nome da branch]. 


# Git Bash 


C:\Repos\eShopOnWeb> git checkout features/feature-02 





Agora que estamos no contexto da branch Feature-02, vamos fazer 
uma alteração no código-fonte. No Visual Studio, abra o arquivo 
PublicApi\CatalogBrandEndpoints\List.cs . 


/// <summary> 

/// List 

/// </summary> 

/// <param name="catalogBrandRepository"></param> 
/// <param name="mapper"></param> 

public List( 


TAsyncRepository<CatalogBrand> catalogBrandRepository, 
IMapper mapper) 
{ 
_catalogBrandRepository = catalogBrandRepository; 
_mapper = mapper; 





Conforme descrito anteriormente, vamos adicionar esse arquivo a 
area de Staging do Git e depois executar o comando commit para 
efetivar as alterações na branch. 


# Git Bash 
C:\Repos\eShopOnWeb> git add . 
C:\Repos\eShopOnWeb> git commit ~ 

-m "feature 02 - adicionando o summary" 





Ao contrário do exemplo da feature-01, em que realizamos o merge 
no repositório local, o pull request é realizado no repositório remoto, 
e, por esse motivo, devemos enviar essa branch para o GitHub 
utilizando o comando git push. 


# Git Bash 
C:\Repos\eShopOnWeb> git push ` 


--set-upstream origin features/feature-02 





PS C:\Repos\eShopOnWeb> git push origin features/feature-02 
Enumerating objects: 11, done. 
Counting objects: 100% (11/11), done. 
Delta compression using up to 8 threads 
Compressing objects: 100% (6/6), done. 
Writing objects: 100% (6/6), 590 bytes | 590.00 KiB/s, done. 
Total 6 (delta 5), reused 6 (delta 0), pack-reused 0 
remote: Resolving deltas: 100% (5/5), completed with 5 Local objects. 
remote: 
remote: Create a pull request for 'features/feature-02' on GitHub by visiting: 
remote: https://github.com/Leandrotestes/TesteLeandroPrado/pull/new/features/feature-02 
remote: 
To https://github.com/Leandrotestes/TesteLeandroPrado.git 
* [new branch] features/feature-02 -> features/feature-02 
Branch 'features/feature-02' set up to track remote branch 'features/feature-02' from 'origin'. 





Figura 6.26: Resultado do comando Git Push. 


Todo processo do pull request é realizado através do portal do 
GitHub. Quando acessar o repositório, você perceberá que a nova 
branch foi enviada e que você poderá iniciar um novo procedimento 
de merge utilizando o pull request. Clique no botão Compare & Pull 
Request. 


<> Code Issues Pull requests Actions Projects Security Insights Settings 


F features/feature-02 had recent pushes 1 minute ago Compare & pull request 
P master ~ E 2branches © 0 tags Go to file Add file ~ 


6 Isprado initial commit 5212d32 8 daysago )1commits 

src initial commit 8 days ago 
D  .gitignore initial commit 8 days ago 
[) LICENSE initial commit 8 days ago 
[3 README.md initial commit 8 days ago 
D eShopOnWweb.sln initial commit 8 days ago 








Figura 6.27: Branch enviada para o GitHub. 


Neste momento, podemos adicionar algumas informações para 
auxiliar no processo de aprovação, como título e descrição. Se seu 


time estiver utilizando /ssue para gerenciar o trabalho, vocé podera 
associa-lo ao seu pull request. Você também poderá selecionar 
quem será responsável por realizar a revisão de código desse pull 
request. Na seguinte figura, podemos ver como o nosso pull request 
ficará configurado: 


NOTA 


Issues é o modelo utilizado pelo GitHub para que o time possa 
planejar, organizar as tarefas que gostariam de realizar, coletar 


feedback do usuário e relatar bugs de software. 


Para mais detalhes, acesse o link 
https://docs.github.com/en/github/managing-your-work-on- 
github/about-issues. 





tf base: master» © compare: features/feature-02 v v Able to merge. These branches can be automatically merged. 
O feature 02 - adicionando o summary Reviewers 
E joseotaviog e 
Write Preview 
Assignees 
b BZES d ZEW @ ZZ So i g 
—assign y< 
Leave a comme 
Labels 
Projects 
Book - eShopOnWeb 
Milestone 
Attach files by dragging & dropping, selecting or pasting them co 
= E = = No milestone 
Create pull request 
Linked issues © 
© Remember, contributions to this repository should follow our GitHub Community Guidelines. Use Closing keywords in the description 
to automatically close issues 


Figura 6.28: Criação de um Pull Request. 


Na parte inferior, é possível ver todos os commits e todos os 
arquivos, que foram alterados na feature branch, e compara-los com 
a versao atual. Dessa forma, temos uma visao de todas as 
alterações realizadas. 


©- 1 commit TO 1 file changed ( 0 comments AR 1 contributor 





E} Commits on Oct 21, 2020 


(a) feature @2 - adicionando o summary 886535a 


Showing 1 changed file with 5 additions and 0 deletions. Unified Split 


v 5 HEHEHE src/Publicapi/CatalogBrandEndpoints/List.cs B 


sa @@ -15,6 +15,11 @@ public class List : BaseAsyncEndpoint<ListCatalogBrandsResponse 


private readonly IAs Repository<CatalogBrand> _catalogBrandRepository; 





private readonly IMapper _mapper; 


/ <summary 


summary 


/ <param name="catalogBrandRepository"></param 


+ + + + + 


/ <param name="mapper"></param 
public List(IAsyncRepository<CatalogBrand> catalogBrandRepository, 
IMapper mapper) 


{ 


Figura 6.29: Detalhes do Pull Request. 


A pessoa responsável por revisar o código vai receber um e-mail de 
notificação e deverá acessar o pull request para revisar o código. O 
revisor pode comentar as alterações realizadas até que esteja de 
acordo com as políticas e qualidade definidas pelo time. 


feature 02 - adicionando o summary #2 Est Open with ~ 


pe leandromsft wants to merge 2 commits into master from features/feature-oz D 


Conversation 0 Commits 2 Checks 0 Files changed 1 -5-0 Tuma 


a ass SSS 


E Finish your review 
> 5 BERRE src/PublicApi/CatalogBrandEndpoints/List.cs D 





Write Preview HB ZI E os =i & O Ẹ f- 











O ProTip! Use n and p tone 


Revisado e pronto para o merge 








Comment 
O Approve 


Request changes 


Figura 6.30: Revisão e Aprovação do Pull Request. 


Após todo o processo de revisão ter sido aprovado, podemos 
completar o pull request. Nesse momento, o GitHub realizará o 
merge de todos os arquivos que alteramos na branch feature-02 
para a branch master. 


Add more commits by pushing to the features/feature-02 branch on CEProjectFalcon/eShopOnWeb. 


EO € © Review requested Hide all reviewers 


Review has been requested on this pull request. It is not required to merge. Learn more. 





2, 1 pending reviewer 


Ku joseotaviog was requested for review 


This branch has no conflicts with the base branch 
Merging can be performed automatically. 


Merge pull request ME You can also open this in GitHub Desktop or view command line instructions. 











Figura 6.31: Pull Request Finalizado. 


6.7 GitHub Actions 


GitHub Actions é um workflow para automatização do processo de 
Continuous Integration onde vocé pode configurar um conjunto de 
tarefas para executar o procedimento de build da sua aplicação e 
todos os Unit Tests para validar seu código-fonte. Todos os 
workflows são escritos utilizando a sintaxe YML e são baseados em 
eventos que podem ser executados em máquinas fornecidas e 
suportadas pelo GitHub ou por máquinas mantidas por você. 


Atualmente o GitHub Actions provê suporte para diferentes 
linguagens e frameworks, como .NET Core, Java, Python, Docker, 
Terraform. 


Mas antes de começar a utilizar o GitHub Actions, temos que 
entender duas práticas muito utilizadas atualmente pelas empresas: 
Integração Contínua e Entrega Contínua. 


Integração Contínua (Continuous Integration (Cl), em inglês) é o 
processo de automatização do build e execução dos testes unitários 
toda vez que um membro do time realiza um novo commit no 
controle de versão. O Cl incentiva os desenvolvedores a 
compartilhar seu código e testes unitários em um repositório 
compartilhado após cada alteração. Ao fazer o commit do código, é 
acionado automaticamente um workflow de build para compilar, 
testar e validar as últimas alterações realizadas. 


Entrega Contínua (Continuous Delivery (CD), em inglês) é o 
processo automatizado para publicar uma nova versão no ambiente 
produtivo o mais rápido possível. O processo de Cl pode iniciar um 
CD que, por sua vez, vai passar por toda a esteira de publicação, 
por exemplo DEV -> HML -> PRD. Outra prática utilizada é liberar as 
versões de maneira progressiva, também chamada de rings, onde 
podemos liberar uma nova versão aos poucos para um conjunto 
predeterminado de usuários, assim podemos monitorar a 
experiência do usuário com a nova versão. Outras duas práticas de 
CD são o Blue/Green e Feature Flags para experimentar novas 
features. 


A seguinte figura demonstra a estrutura padrao de um workflow: 





Actions 


Actions 


Actions 


Figura 6.32: Estrutura básica do workflow. 


Workflow é um procedimento automatizado que você pode 
adicionar em seu repositório. Um workflow pode executar um ou 
mais jobs e pode ser agendado ou iniciado por um evento, por 
exemplo pull request. Pode ser usado para build, testes, empacotar 
ou publicar um projeto. 


Evento é uma atividade específica que inicia um workflow. Por 
exemplo, alguém realiza um push de um commit no repositório ou 
um pull request é criado. Você também pode configurar um evento 
externo utilizando um webhook. 


Runner é um servidor que possui o agente do GitHub Actions 
instalado. Você pode usar um runner hospedado pelo GitHub ou 
você pode hospedar o seu próprio. Um runner escuta os jobs 
disponíveis, executa um job por vez e relata o progresso, logs e os 
resultados de volta ao GitHub. Para os runners hospedados no 
GitHub, cada job é executado em um ambiente virtual novo. 


Job é um conjunto de etapas executadas no mesmo runner. Por 
padrão, um workflow com vários jobs executará esses trabalhos em 


paralelo. Vocé também pode configurar um workflow para executar 
tarefas sequencialmente. Por exemplo, um workflow pode ter dois 
jobs sequenciais, um job que realiza o build e outro job que executa 
os testes, sendo que o job de testes depende do status do job de 
build. Se o job de build falhar, o job de teste não sera executado. 


Step é uma tarefa individual que pode rodar um comando. Cada 
step dentro do job é executado pelo mesmo processo (Runner) 
fazendo com que as actions compartilhem informações. 


Actions são comandos independentes combinados em steps para 
criar um job. Actions são o menor bloco dentro de um workflow. 
Você pode criar suas próprias actions ou usar actions criadas pela 
comunidade GitHub. 


A seguir temos um exemplo básico de um workflow: 


name: my-workflow 
on: [push] 
jobs: 


check-bats-version: 
runs-on: ubuntu-latest 
steps: 
- uses: actions/checkout\@v2 
- uses: actions/setup-node\@v1 
- run: npm install -g bats 
- run: bats -v 





6.8 Criando um workflow no GitHub Actions 


Nesta seção, vamos configurar um workflow de Cl para o projeto 
eShopOnWeb. Para isso, acesse o repositório no GitHub e clique no 
menu Actions. Baseado em nosso repositório, o GitHub vai sugerir 


alguns modelos de workflow. Como o projeto eShopOnWeb é 
baseado em .Net Core, podemos selecionar o template .NET Core, 
conforme a seguinte figura. 


8 CEProjectFalcon / eShopOnWeb | Private Owatch- 2 star 0 | Yok O 


Code Issues Pull requests © Actions Projects 1 Security Insights Settings 








Skip this and set up a workflow yourself > 


Workflows made for your C# repository 


-NET Core O .NET Core Desktop O 
By GitHub Actions By GitHub Actions 


or ASP.NET Core project Build, test, sign and publish a desktop application built on .NET Core. 


Set up this workflow 





D actions/starter-workfiows e D actions/starter-workfiows co 


Figura 6.33: Criar um Workflow. 


Será aberto um template YML com um workflow base para iniciar 
nosso processo de Cl. Vamos configurá-lo conforme o workflow a 
seguir: 


name: eshoponweb-ci 


on: 
push: 
branches: [ master ] 
pull request: 
branches: [ master ] 


jobs: 
build: 


runs-on: ubuntu-latest 


steps: 
- uses: actions/checkout@v2 


name: Setup .NET Core 


uses: actions/setup-dotnet@v1 
with: 
dotnet-version: 3.1.301 


name: Install dependencies 
run: dotnet restore 


name: Build API 
run: dotnet build src/PublicApi/PublicApi.csproj 
--configuration Release --no-restore 


name: Build Web 
run: dotnet build src/Web/Web.csproj 
--configuration Release --no-restore 





Na tabela a seguir, descrevemos todos os componentes utilizados 
nesse workflow. 


Nome Descrição 


Nome 


name: eshoponweb-ci 


on: [push] 


jobs 


runs-on: ubuntu-latest 


steps 


uses: actions/checkout@v2 


uses: actions/setup- 
dotnet@v1 


run: dotnet restore 


Descrição 


Nome do workflow que vai aparecer 
na aba Actions 


Especifica o evento que vai iniciar 
automaticamente esse workflow. 
Nesse exemplo, estamos usando o 
evento push para a branch master e o 
evento de pull request para a branch 
master 


Grupo de todos os jobs que serão 
executados. Nesse exemplo, o nome 
do nosso job é Build 


Onde o job será executado. Nesse 
exemplo, em uma máquina virtual com 
Ubuntu 


Grupo com todas as tarefas que serão 
executadas dentro do job Build 


A palavra-chave uses fala para o job 
recuperar a versão v2 da action 
checkout. Essa action vai verificar seu 
repositório e baixar o conteúdo para o 
runner. 


Essa action instala a versão do .Net 
Core na máquina onde o runner está 


rodando, dando acesso ao comando 
dotnet 


Executa o comando restore para 
restaurar todos os pacotes do projeto 


Nome Descrição 


Executa o comando build para 
run: dotnet build compilar a aplicação passando como 
parâmetro a configuração de Release 


Para finalizar o processo de configuração, devemos salvar nosso 
workflow. Clique no botão Start Commit e, logo em seguida, no 
botão Commit Changes. Neste momento, o GitHub dispara uma 
nova execução do nosso workflow, então clique no menu Actions 
para ver o workflow sendo executado. 


Code Issues Pull requests © Actions Projects 1 Security Insights Settings 
Workflows New workflow  eshoponweb-ci 
All workflows workflow:eshoponweb-ci x] 
2, eshoponweb-a 
3 results Event = Status ~ Branch ~ Actor ~ 
@ Update eshoponweb-ci.yml 5 
3: Commit 4637940 pushed by lea capitulo2 secondsago *** 


eandromsft 


eshoponweb-ci #3: Co 


Figura 6.34: Execução de um workflow. 


Clique em cima da execução para visualizar os logs detalhados de 
cada uma das steps conforme a seguinte figura. 


O Update eshoponweb-ci.yml 


v eshoponweb-ci 


buid Set up job 


Run actions/checkout@v2 


Setup .NET Core 


install dependences 


Build API 

> Rum dotnet build src/PublicApi/PublicApi.csproj --configuration Release - -res e 
7 Microsoft (R) Build Engine version 16.6.0+5ff7t for .MET Core 

Copyright (C) Microsoft Corporation. All rights reserved. 


Build Web 


Post Run actions/checkout@v2 





Figura 6.35: Detalhes da execução do workflow. 
Publicando a aplicação 


No capítulo anterior, todo o processo de publicação foi realizado 
manualmente utilizando scripts e usando a linha de comando az 
cli . Agora vamos automatizar todo o processo de publicação 
utilizando o GitHub Actions. 


Crie um workflow chamado eshoponweb-cd e configure conforme o 
workflow anterior eshoponweb-ci. Devemos configurar os passos 
para fazer o deployment da aplicação adicionando as seguintes 
actions. 





name: Publish API 

run: dotnet publish src/PublicApi/PublicApi.csproj 
--configuration Release --output ApiPublish 
--no-restore 


name: Publish Web 

run: dotnet publish src/Web/Web.csproj 
--configuration Release --output WebPublish 
--no-restore 


name: Tar API 
run: tar -czvf api.tar.gz -C ApiPublish 


name: Tar Web 
run: tar -czvf web.tar.gz -C WebPublish 


name: Artifact API 
uses: actions/upload-artifact@v2 
with: 

name: api 

path: api.tar.gz 


name: Artifact Web 
uses: actions/upload-artifact@v2 
with: 

name: web 

path: web.tar.gz 


name: Login Azure 

uses: azure/login@v1 

with: 
creds: ${{secrets.AZURE_CREDENTIALS}} 
enable-AzPSSession: true 


name: Upload api.tar.gz to Azure Blob Storage 

run: az storage blob upload 
--account-name ${{secrets.STORAGE_ACCOUNT_NAME }} 
--account-key $((secrets.STORAGE ACCOUNT KEN) 
--container-name stcdeployche@e1 


--file api.tar.gz --name api.tar.gz 


- name: Upload web.tar.gz to Azure Blob Storage 
run: az storage blob upload 
--account-name ${{secrets.STORAGE_ACCOUNT_NAME }} 
--account-key ${{secrets.STORAGE_ACCOUNT_KEY}} 
--container-name stcdeployche@e1 
--file web.tar.gz --name web.tar.gz 


- name: Run reimage command 
uses: azure/powershell@v1 
with: 
azPSVersion: '3.1.0' 
inlineScript: | 
az vmss list-instances -g rg-eshoponweb 
-n vmss-web-ch-001 --query [*].instanceId 
| ConvertFrom-Json | ForEach-Object 
{ az vmss reimage -g rg-eshoponweb -n vmss-web-ch-001 
--instance-id $ } 





Na tabela a seguir, descrevemos todos os componentes utilizados 
para fazer a publicação. 


Nome Descrição 


Realiza o procedimento de empacotamento 
da aplicação e salvamos em um diretório 
separado 


run: dotnet 
publish 


Compactamos a pasta onde foi realizada a 
run: tar -czvf 


publicação 
eek Geramos os artefatos para deixar salvo 
actions/upload- À 
artifact@v2 como anexo no resultado do build 
uses: Realiza o login no Azure utilizando as 


azure/login@v1 credenciais configuradas no GitHub Secret 


Nome Descrigao 


, Faz o upload do arquivo tar.gz para o Azure 

run. az storage . ~ 

blob. upload Blob Storage. Esses arquivos serao 
copiados para dentro das maquinas 


Executa o comando PowerShell para listar 
todas as instâncias e reexecuta a imagem 
com a nova versão da Web e da Api 


uses: 
azure/powershell@v1 


Perceba que estamos usando uma variavel chamada 
${{secrets.AZURE_CREDENTIALS}} . Ela é necessária para nao deixar as 
credenciais de autenticação expostas dentro do workflow, pois isso 
é uma falha de segurança. Para contornar esse problema, o GitHub 
possui uma configuração chamada secrets. 


GitHub Secrets são variáveis de ambiente criptografadas que você 
cria em uma organização ou em um repositório. Os secrets servem 
para guardar informações sigilosas, como usuário, senha, chaves de 
criptografia etc. O GitHub garante que chaves cadastradas sejam 
criptografadas antes de chegarem ao GitHub e que permaneçam 
criptografadas até que você as utilize em um fluxo de trabalho. 


Para criar uma nova secret , clique em Settings-> Secrets -> New 
Secret conforme a seguinte figura. 


> Code © Issues 1) Pull requests 1 ©) Actions [M] Projects © Security | Insights 
Options Secrets 


Manage access 
Secrets are environment variables that are encrypted and only exposed to selected actions. Anyone with 


Security & analysis collaborator access to this repository can use these secrets in a workflow. 

fonek Secrets are not passed to workflows that are triggered by a pull request from a fork. Learn more. 
Webhooks 

Notifications There are no secrets for this repository. 


i . Encrypted secrets allow you to store sensitive information, such as access tokens, in your repository. 
ntegrations 


Deploy keys 


Actions 


Figura 6.36: Criar uma nova secret. 


Repita esse mesmo processo para criar as secrets 
$((secrets.STORAGE ACCOUNT NAMEJ) € ${{secrets.STORAGE_ACCOUNT_KEY}} 
que serão utilizadas para acessar o Azure Storage. 


Ao final devemos ter as seguintes secrets criadas. 


Secrets New secret 


Secrets are environment variables that are encrypted and only exposed to selected actions. Anyone with collaborator access to this repository can 
use these secrets in a workflow. 


Secrets are not passed to workflows that are triggered by a pull request from a fork. Learn more. 


Repository secrets 


Ê AGURE CREDENTIALS Updated 5 days ago Update Remove 
8 STORAGE_ACCOUNT_KEY Updated 8 hours ago Update Remove 
O STORAGE ACCOUNT NAME Updated 8 hours ago Update Remove 


Figura 6.37: Secrets criadas. 


Após todas as configurações, devemos salvar nosso workflow. 
Clique no botão Start Commit. Será disparada uma nova execução 
do workflow de deployment. Para ver os detalhes do processo, 
clique sobre a execução e você poderá ver os logs da execução. 


© Update eshoponweb-ci.yml artifacts O - © inne = 


capitulo2 © © c0a8616 
v eshoponweb-cd 
v build 
Publish API 
Publish Web 
Tar API 
Tar Web 
Artifact API 
Artifact Web 
Login Azure 
Upload api.tar.gz to Azure Blob Storage 
Upload web.tar.gz to Azure Blob Storage 
Run reimage command 


Post Run actions/checkout@v2 


© 
Q 
© 
© 
© 
© 
@ 
© 
iv) 
© 
© 
© 


Complete job 





Figura 6.38: Execução do processo de deployment. 


6.9 Resumo 


Neste capítulo, conseguimos adotar o processo de gerenciamento 
de código-fonte abordando os seguintes tópicos: 


e Importância de controlar as versões do código-fonte. 

Guia básico da utilização dos comandos Git. 

Como trabalhar de forma paralela com a utilização de branches. 

e Configuração do GitHub Action para executar o processo de Cl 
e CD. 


No próximo capítulo, vamos iniciar o processo de monitoramento da 
aplicação eShopOnWeb. 


CAPITULO 7 
Monitoramento da solução 


Escrito por Demetrio Costa, James Jodai e Rafael Teixeira. 


CENÁRIO 


Para realizar a modernização da aplicação eShopOnWeb é 
recomendado que façamos a monitoração da solução a fim de 
entender suas características, padrões de uso, performance e 
possíveis erros. Na verdade, a monitoração é sempre 
recomendada para aplicações produtivas por trazer inúmeros 
benefícios. 


Neste capítulo, abordaremos os seguintes assuntos: 


e O que é monitoração e a sua importância. 
e Como implementar a monitoração em aplicações. 
e Como resolver problemas através da monitoração. 





Aqui falaremos em detalhes sobre o monitoramento de aplicações e 
soluções, desde sua importância, uso básico e avançado para os 
cenários técnicos, até o apoio ao negócio no que tange nossas 
aplicações. Dessa forma, não vamos entrar em detalhes sobre o 
monitoramento de soluções gerenciadas, como sistemas de banco 
de dados, serviços de mensageria, serviços de cache. Muitos 
desses serviços já possuem alguma solução de monitoramento 
embarcada, especialmente quando falamos deles como plataforma 
como serviço (PaaS) disponíveis nos provedores de Cloud. 


A monitoração é o ato de coletar e dar visibilidade a diversos 
aspectos de uma aplicação, sejam eles técnicos, como quantidade 
de transações por segundo (TPS), quantidade de erros, percentual 
de uso de processamento e memória; sejam outros, como 


quantidade de usuarios on-line, numero de vendas efetuadas, 
desistências, tempo médio de compra, entre outros, tudo o que for 
necessário para entender seu negócio e melhorar seu produto. 


Conseguimos construir uma visão ampla de nossas aplicações 
contando com métricas, eventos e traces que nos ajudam a evitar e 
prever problemas, resolvê-los mais rapidamente e evoluir a 
aplicação com base na experiência dos usuários, pilar essencial na 
prática de DevOps. Lembre-se de que Aquilo que não se pode medir 
não se pode melhorar (William Thomson). 


Atualmente estamos vivendo um momento em que os padrões de 
desenvolvimento estão voltados para aplicações extremamente 
modulares (distribuídas) para que seja possível extrair todos os 
benefícios da computação em nuvem, que possibilitam a construção 
de sistemas realmente escaláveis, resilientes e performáticos, de 
forma nunca vista anteriormente. Isso realmente é algo muito 
benéfico para qualquer negócio que esteja apoiado em sistemas 
digitais e, hoje em dia, a maioria deles apoia o negócio e, em alguns 
casos, suporta a estratégia e geração de vantagem competitiva de 
uma empresa. 


Já parou para pensar na complexidade adicionada através dessas 
arquiteturas distribuídas (diversas integrações) para encontrar um 
problema? Imagine um cenário muito comum em que uma aplicação 
web de e-commerce recebe uma requisição de compra por um 
usuário. Para efetivar essa compra, a aplicação chama outros dois 
serviços, o de estoque e o de pagamento, mas durante esse 
processamento ocorre um erro e ele é retornado para o usuário. 
Como identificamos se o problema ocorreu no site principal do e- 
commerce, no serviço de pagamento ou no do estoque? Ou ainda, 
em um cenário mais complexo no qual as requisições de compras 
estão extremamente lentas, como sabemos de onde vem essa 
lentidão? 


Essas respostas podem ser obtidas em questões de minutos 
quando se tem uma aplicação monitorada corretamente, seja essa 


monitoração feita manualmente ou através de produtos de 
mercados, conhecidos como Application Performance Management 
(APM). 


Criar uma monitoração própria para uma aplicação não é uma tarefa 
simples, precisamos codificar componentes que fariam diversos 
tipos de coletas, como evento, métricas, logs e outros, isso tudo 
sem afetar a performance da aplicação monitorada. Além disso, 
teríamos que desenvolver uma ferramenta para visualização e 
exibição dessas informações de forma útil. Esse foi apenas um 
simples exemplo para mostrar a complexidade que existe em 
construirmos uma monitoração para nossas aplicações e apenas em 
raras exceções essa abordagem é recomendada. 


As ferramentas de APM fornecem inúmeras visões: desde um 
panorama geral até o segmento de código onde ocorreu o problema. 
São facilmente acopladas em quaisquer aplicações, como Java, 
Net, Node.js, Python, muitas vezes sem a necessidade de escrever 
uma linha de código. São capazes de monitorar aplicações cliente- 
servidor, web, serviços, rotinas e qualquer outro tipo de aplicação. 
Além disso, são imprescindíveis para aplicações que prezam pela 
experiência do usuário e têm interesse em serem competitivas e 
diferenciadas. 


Neste capítulo, falaremos sobre o APM da Microsoft, o Application 
Insights, que é um serviço disponível no Microsoft Azure e utilizado 
para monitorar aplicações hospedadas em data centers locais (on- 
premises) ou na nuvem (Cloud). Suas características serão 
exploradas em detalhes a fim de extrair o máximo desse produto. 


@ appi-eshoponweb en 








Application Insights 
D Pesquisar (Ctrl+/) « dk Painel do Aplicativo Gu Introdução D Pesquisar E Logs KA Grupo de recursos do monitor © Comentários Tr 
E visão Geral Mostrar dados para o último: 30 minutos BRIZ choras 12 horas 1 dia 3 dias 7 dias 30 dias 


a Log de atividade 
fa, IAM (Controle de acesso) Solicitações com falha <> Tempo de resposta do servidor E 


6 Marcações 


150ms 
& Diagnosticar e resolver proble... 
E 100ms 
Investigar E 
= dE 1 50ms 
=” Mapa do aplicativo 
%& Detecção Inteligente 0 Oms 


14:45 15 15:30  UTC-03:00 14:45 15 1530 UTC-03:00 
A Live Metrics Failed requests (Contagem) Server response time (Média) 
appi-eshoponweb ppi-eshoponweb 
p Pesquisa de transação 3 31,95 ms 
® Disponibilidade 
mt Falhas Solicitações do servidor Ea Disponibilidade x 


% Desempenho 


E Guias de solução de problema.. 30 


Figura 7.1: Visao principal do Application Insights. 


7.1 Ativagao da monitoragao com Application 
Insights 


A nossa proposta aqui será a utilização da nossa aplicação de 
exemplo (eShopOnWeb) para configurarmos o Application Insights, 
e assim já demonstrarmos a coleta de algumas métricas que são 
ativadas por padrão. 


Criação do recurso 
Um pré-requisito para a utilização do Application Insights é a criação 


do recurso no portal do Azure. Esse recurso será responsável pelo 
armazenamento das informações enviadas pela aplicação. 


Caso nao tenha um recurso do Application Insights criado no Azure, 
entre no portal e crie o recurso Application Insights. Existem outras 
formas para automatizar a criação de um recurso no Azure através 
da utilização do Azure CLI, Poweshell ou ARM templates. 


No trecho a seguir, temos um exemplo de criação do recurso 
utilizando Azure CLI. 


az extension add -n application-insights 


az monitor app-insights component create --app <nomeappinsights> 
--location brazilsouth --resource-group <resourcegroupname> 
--kind web --application-type web 





Após a criação do recurso no Azure, podemos visualizar as 
propriedades do Application Insights através do portal: 


Home > 


@ appi-eshoponweb dn x 
Application Insights 
dk Application Dashboard 4 Getting started Ø Search d Logs E Monitor resource group © Feedback yg Favorites + 


^A Essentials View Cost | JSON View 


Resource group (change) Instrumentation Key 
rg-eshoponweb 


Location Connection String 


Brazil South Instrumentationkey= HDD. 


Subscription (change) 
Microsoft Azure Internal Consumption 


Subscription ID 


Figura 7.2: Recurso Application Insights criado no Azure. 


Na figura anterior, o valor do campo Chave de Instrumentação em 
destaque é utilizado para configurarmos uma aplicação. 


Instalação do SDK do Application Insights 


O SDK (Software Development Kit) do Application Insights é 
responsavel pelo fornecimento de toda a infraestrutura necessaria 
para utilização da ferramenta como conectividade com o Azure e 
quais os tipos de informações e métricas que serão coletados. 


Podemos utilizar o SDK com vários tipos de aplicações, como: 


e ASP.NET Applications; 

e ASP.NET Core Applications; 

e .NET Console Applications; 

e Windows Services Applications; 
e Java; 

e Node.js; 

e Python. 


Para cada tipo de aplicação existe um pacote mais adequado para 
instalação, o que garante que todas as dependências necessárias 
também sejam instaladas. Por exemplo, para aplicações Asp.Net, 

basta instalar o pacote Microsoft.ApplicationInsights.Web . 


No nosso caso, vamos abrir a nossa aplicação eShopOnWeb 
utilizando o Visual Studio para adicionarmos o SDK do Application 
Insights. 


Solution Explorer 
OR: br ZE br d 
Search Solution Explorer (Ctrl+;) P~ 
ala) Solution eShopOnwWeb (10 of 10 projects) 
b ii Solution Items 
d & SIC 
> als] ApplicationCore 
b ai] BlazorAdmin 
b afe#] BlazorShared 
p 
p 





elea Infrastructure 
af) PublicApi 





Figura 7.3: Solução eShopWeb. 


Lembrando que a aplicação eShopOnWeb foi desenvolvida em 
ASP.Net Core, vamos adicionar o pacote 
Microsoft.ApplicationInsights.AspNetCore . 


Browse Installed Updates 


Applicationinsights x - © [] Include prerelease 





9 Microsoft.ApplicationInsights.AspNetCore © by Microsoft, 38.7M downloads v2.15.0 


E Application Insights for ASP.NET Core web applications. See https://azure.microsoft.com/documentation/articles/ 
app-insights-asp-net-five/ for more information. Privacy statement: https://go.microsoft.com/fwlink/?Linkld=512156 


Figura 7.4: Application Insights SDK para AspNetCore. 


Uma outra forma de instalar o pacote é utilizando o CLI do .NET 
Core. 


dotnet add package Microsoft.ApplicationInsights.AspNetCore 





Após a instalação do SDK, é necessário habilitar o Application 
Insights dentro do método ConfigureServices (Startup.cs) . 


public void ConfigureServices(IServiceCollection services) 


{ 
services .AddApplicationInsightsTelemetry() ; 





Outra configuragao necessaria para habilitar a coleta de 
informações da aplicação é a adição da chave de instrumentação no 
arquivo appsettings.json da aplicação. 


{ 
"ApplicationInsights": { 


"InstrumentationKey": "<chavedeinstrumentacao>" 
>, 
} 





A chave de instrumentação pode ser obtida nas propriedades do 
recurso Application Insights no Azure. 


Visualização das informações no Application Insights 


Após a configuração da aplicação com o SDK, a coleta e o envio de 
informações sobre o funcionamento da aplicação já é iniciada e os 
dados passam a ser enviados para o Azure, onde podemos 
acompanhar instantaneamente as informações sobre a aplicação. 


Acessando o recurso Application Insights no Azure, na opção Visão 
Geral já podemos visualizar algumas informações de forma gráfica 
de como está a saúde de uma aplicação, como solicitações que 
geraram falhas, tempo de resposta do servidor, fluxo de solicitações 
que chegaram à aplicação e disponibilidade da aplicação. 


Informações de desempenho 


A análise de informações de desempenho da aplicação é muito 
importante para que possamos decidir quais ações precisaremos 
tomar para que a performance da aplicação esteja em um nível 
acordado com os usuários de negócio. Por exemplo, suponhamos 
que temos uma funcionalidade específica da aplicação na qual, 
através dessas informações de desempenho, notamos que o tempo 
de resposta não está em um nível aceitável. Dependendo da 
análise, podemos atuar na melhora da performance dessa 
funcionalidade ou aumentar os recursos computacionais para a 
adequação do desempenho da solução. 


Nessa visão de dados, podemos visualizar a média do tempo de 
resposta para as requisições, que foram solicitadas para a 
aplicação, além de filtrar os períodos específicos. 


Selecionar operação 


NOME DA OPERAÇÃO DURAÇÃO (MÉDIA) ^4 CONTAG... FIXAR 





Geral 
GET /css/basket/basket-status/basket-status.component.css 


GET /css/basket/basket.component.css 


POST /Basket/Index 





A 
u 


POST /Basket/Checkout 





Ê GET /Basket/Checkout 


GET /Basket/Success 


SES 
3 
“ 
o 


GET /Basket/Index 


Figura 7.5: Tempo de resposta médio das requisições. 


Caso queiramos analisar uma requisição específica, podemos 
visualizar uma amostra para visualizar mais detalhes. Essa análise é 
importante para entender em quais pontos da aplicação está 
distribuída a duração total de uma solicitação. 


Transação de ponta a ponta 
ID da Operação: 512cadf737834800b6c3fa979779ab02 :® 


B = solicitação (de entrada) YZ = Dependência (de saída) Á = Exceção E = Rastreamento do Profiler @l = Depurar instantâneo 
EVENTO CoD. DURAÇÃO Yo 200 MS 400 MS 600 MS bd 
v O Test East US 749 ms EEB BREEÉ£A-£*—*-£XAX EB 


» Não há nenhum resultado do teste na Web salv 








da eae tee d e erat parren 


E sql-eshoponweb-ch-001  Microsoft.eS 118 ms WU, 
D sql-eshoponweb-ch-001 Microsoftes 118 ms WMI A, 
E sql-eshoponweb-ch-001  Microsoftes 118 ms WU A, 


Figura 7.6: Detalhe de uma requisição. 


Informações de falhas 


Outro benefício que podemos ter com a utilização do Application 
Insights é a possibilidade de visualizar informações das requisições 


que falharam. 


Essas informações são muito importantes para a análise de 
melhoria da aplicação e para o processo de análise de falhas que 
será visto com mais detalhes neste capítulo. 


iy appi-eshoponweb | Falhas < 


Application Insights 


Operações Dependências Exceções Funções 


Falha na contagem de solicitação * 


1 


500m 








18:00 21:00 ter. 23 03:00 06:00 09:00 12:00 15:00 
18:00 21:00 ter. 23 03:00 06:00 09:00 12:00 15:00 


Selecionar operação D indexh 
NOME DA OPERAÇÃO CONTAGEM (COM ...'y CONTAG... FIXAR 
Geral 136 36.03 | 
l POST /index.html 14 14 
GET /index.html 11 11 


Figura 7.7: Visualização de requisições com falhas. 
Informações de testes de disponibilidade 


Outra funcionalidade muito importante é o teste de disponibilidade 
da aplicação. Podemos configurar testes de disponibilidade para 
páginas específicas e também para fluxos de negócios mais 
elaborados, com mais de uma página. 


Além disso, podemos configurar a frequência do teste e, em casos 
de falhas, gerar alarmes sinalizando a ocorrência da falha para um 
determinado grupo e até mesmo disparar outras ações, como uma 
função no Azure ou WebHook. 


o appi-eshoponweb | Disponibilidade d 


Application Insights 
ek Adicionar teste OO Atualizar B Exibir nos Logs D SLA Report D Copy link ? Solucionar problemas 


Hora Local: Ultimos 30 dias KA 





Disponibilidade Ed ( Linha Gráfico de Dispersão 





15 sec 





2. e 
Sa e, p x 
E BA « E NM y ra 
0.0ms 
dom. 31 dom. 7 dom. 14 dom. 21 
dom. 31 dom. 7 dom. 14 dom. 21 
1604 [1604 | 
Selecionar o teste de disponibilidade PP Pesquisar para filtrar itens... 
TESTE DE DISPONIBILIDADE ti 20MIN DISPONIBILI...': DURAÇÃO (MÉDIA) * 
ll Geral 100.00% 100.00% 1.14 sec 
> @ Test 100.00% 100.00% 1.14 sec ZA | 


Figura 7.8: Informações de testes de disponibilidade. 
Mapa do aplicativo 


O mapa do aplicativo fornece uma visão geral de como a aplicação 
está conectada com suas dependências, como banco de dados e 
APIs. A partir dessa visão é possível visualizar também os tempos 
médios de resposta com as dependências da aplicação. 


C 


=. appi-eshoponweb | Mapa do aplicativo x» = 
ei 
hora - appi-eshoponwet 


Application Insights | Ultimo 
Õ Atualizar © Comen tarios [Ef Sugerir uma ideia q Saiba mais 7? Solução de Problemas za Experimentar a versão prévia 


Última hora 


Excluir os 4xx: @ Desligado Layout: @ 


2 
9 E > instancias —_, ~ 
m 100% 1.3 s E 324 ms 130.5 ms 7 SQL 


62 testes 1.4K chamadas 152 chamadas 
Test 


DISPONIBILIDADE 











sql-eshopo....CatalogDb 
SQL 


Web-Frontend 


Figura 7.9: Visão geral através do mapa do aplicativo. 


7.2 Monitoração customizada 


Uma das vantagens de se trabalhar com o Application Insights como 
ferramenta de monitoração é a possibilidade de customizar como as 
métricas e eventos são organizados e enviados ao portal do Azure. 
Essa customização permite enriquecer os dados e torná-los mais 
relevantes para a aplicação e o negócio. 


Para exemplificar, continuaremos efetuando modificações na 
aplicação de exemplo eShopOnWeb. Assim explicaremos os 
recursos customizáveis expostos pela API do Application Insights e 
como implementá-los. 


Então vamos para a parte prática! 


Uma vez que já temos o SDK do Application Insights instalado, 
precisaremos adicionar em nosso código uma instância do objeto 
TelemetryClient . 


O Telemetryclient é a classe responsável pelo envio de métricas, 
eventos e demais informações de monitoração. 


private TelemetryClient telemetry = new TelemetryClient(); 





Vamos usar o recurso de injeção de dependência presente no 
ASP.NET Core para fazer uso do objeto Telemetryclient . Vamos 
exemplificar como esse processo é feito em cada um dos próximos 
exemplos de implementação. 


TrackPageView - Server Side 


PageView é uma das métricas mais importantes quando pensamos 
em como nosso website é utilizado. Ela indica a quantidade de 
vezes que uma página é visitada. É habilitada por padrão quando 
instrumentamos nossa aplicação com o SDK do Application Insighis. 


Com base nessa métrica e em como a estrutura de um site é 
organizada, podemos, por exemplo, identificar páginas mais 
acessadas, produtos mais relevantes, tendências de acesso e uso 
de nosso website. 


Para exemplificar, vamos customizar nossa aplicação de modo que 
saibamos o que é mais pesquisado pelos clientes. Para isso, 
alteramos o código do construtor da página Index.cshtml . 


public IndexModel( 

ICatalogViewModelService catalogViewModelService, 
TelemetryClient telemetryClient) 

{ 


_CatalogViewModelService = catalogViewModelService; 
_telemetryClient = telemetryClient; 


} 





E também faremos uma alteração no método oncet , acrescentando 
chamadas para o método TrackPageView: 





public async Task OnGet(CatalogIndexViewModel catalogModel, 
int? pageId) 


if (catalogModel.BrandFilterApplied != null) 
{ 
SelectListItem itemBrand = CatalogModel.Brands.Where( 
brand => 
brand.Value == catalogModel.BrandFilterApplied.ToString() 
).FirstOrDefault(); 


_telemetryClient.TrackPageView(itemBrand.Text) ; 
} 


if (catalogModel.TypesFilterApplied != null) 
{ 
SelectListItem itemType = CatalogModel.Types.Where( 
type => 
type.Value == catalogModel.TypesFilterApplied.ToString() 
).FirstOrDefault(); 


_telemetryClient.TrackPageView(itemType. Text) ; 


} 
} 


appi-eshoponweb, Page views, Soma @ ) ( Y Vi... = .NET, Azure, She... @ | ( 2$ Dividir por = View page name @ 


VIEW PAGE NAME SUM 
NEI 9 
T-Shirt 6 
Sheet 6 
USB Memory Stick 6 
Azure 3 


Visual Studio 3 


Figura 7.10: Número de pageviews associados a itens pesquisados na aplicação. 


Como podemos observar, cada vez que um item é pesquisado, um 
pageview é contabilizado e com isso podemos extrair informações 
relevantes sobre o interesse em uma determinada marca ou tipo de 
produto. 


TrackPageView - Client Side 


O SDK do Application Insights permite várias formas de 
configuração, cada uma adequada ao tipo de aplicação que está 
sendo desenvolvida. Consulte a documentação para encontrar a 
que melhor vai atender ao seu projeto. 


Uma das formas de configuração possível é através da 
instrumentação para coleta de dados relacionados ao 
comportamento da aplicação no lado do cliente (client side). Essa 
forma possibilita a instrumentação de aplicações baseadas em 
frameworks JavaScript, como Angular e React, por exemplo. 


No exemplo proposto, nossa aplicação seguirá a documentação 
para aplicações ASP.NET Core. Neste caso devemos alterar o 
arquivo _ViewImports.cshtml adicionando a seguinte linha: 


@inject Microsoft.ApplicationInsights.AspNetCore. JavaScriptSnippet 


JavaScriptSnippet 





E adicionar o seguinte trecho em _Layout.cshtml dentro da tag head. 


@Htm1.Raw(JavaScriptSnippet.FullScript) 


</head> 





TrackEvent 


E se precisarmos monitorar uma ação, um clique em um botão, uma 
imagem, uma rotina executada”? Como poderíamos registrar o que 
está sendo solicitado? Como registrar tais ações? 


Essas ações podem ser compreendidas como eventos. Uma vez 
que registramos esses eventos, podemos identificar alguns pontos 
relevantes: 


e A frequência com que um evento específico ocorre. 
e A quantidade de vezes que um evento é disparado. 


Para exemplificar, vamos considerar a realização de um pedido 
como um evento. Toda vez que um pedido for realizado com 
sucesso, vamos coletar essa informação com o uso do método 
TrackEvent . 


Neste caso, iniciaremos através da injeção da instância do 
TelemetryClient no construtor da classe checkoutModel.cs . 


public CheckoutModel(IBasketService basketService, 


IBasketViewModelService basketViewModelService, 
SignInManager<ApplicationUser> signInManager, 
IOrderService orderService, 
TAppLogger<CheckoutModel> logger, 
TelemetryClient telemetryClient) 


_basketService = basketService; 

_SignInManager = signInManager; 

_orderService = orderService; 
_basketViewModelService = basketViewModelService; 
_logger = logger; 

_telemetryClient = telemetryClient; 





No método onPost da classe Checkout.cshtml.cs , vamos adicionar 
uma chamada para o método TrackEvent com uma mensagem order 


submitted successfully. 


public async Task<IActionResult> OnPost( 
IEnumerable<BasketItemViewModel> items) 


{ 


_telemetryClient.TrackEvent("Order submitted successfully"); 


return RedirectToPage("Success"); 


} 





Agora vamos realizar os testes e validar como podemos extrair as 
métricas relacionadas a esse evento: 


Review 


PRODUCT PRICE QUANTITY cost 


Roslyn Red Sheet $6.50 16 $136.00 


TOTAL 
$136.00 





Thanks for your Order! 


Continue Shopping... 





Figura 7.11: Pedido realizado. 


TT Exception I ] Metric |[ ] PageView |[ | Request Il Trace 
0 0 0 0 





y [7] Custom Event [_] Dependency 
Boo To 





8:55AM 9:00 AM 9:05 AM 9:10 AM 9:15 AM 9:20 AM 
20 8:54:45 AM and 10/18/2020 9:54:45 AM. Only the most recent 250 events are available for debug sessions. 


10/18/2020 9:51:23 AM - Custom Event 
E Order submitted succesfully 
Operation name: POST /Basket/Checkout Operation ID: 7efc6d6e6126024fa60c38889ca847b6 


10/18/2020 9:51:13 AM - Custom Event 
Order submitted succesfully 
Operation name: POST /Basket/Checkout Operation ID: e05db572842f4f45bad20f62dbc8441b 












Figura 7.12: Visao do Application Insights Search presente no Visual Studio 2019. 


Proper Operator Values 
e o 


Event name Ka Order submitted succes... Y 


Order submitted succesfully 





Figura 7.13: Filtro de pesquisa contendo o evento customizado. 


Através do painel de métricas do Application Insights no Azure 
podemos sumarizar os resultados de todos os pedidos realizados 
dentro de uma determinada faixa de tempo do dia: 





Property Operator 


E appi-eshoponweb, Events, Sum O )| Y | event name 

















Figura 7.14: Total de pedidos recebidos pela aplicação. 


TrackMetric 


Outro importante recurso presente no SDK Application Insights é a 
possibilidade de coletar valores mensuráveis relacionados a eventos 
particulares. Imagine que esteja monitorando um jogo e queira 
armazenar quantos pontos foram feitos pelo jogador A e pelo 
jogador B. Se o jogador A sair do jogo, retornar e realizar um nova 
partida, será possível verificar se ele fez mais pontos que nas 
partidas anteriores? Podemos alterar o nível de dificuldade com 


base na performance desempenhada nas últimas dez partidas 
realizadas? 


Para esses cenários fazemos o uso de método Trackmetric . Vamos 
ilustrar o uso desse recurso com métricas relacionadas aos valores 
de cada pedido realizado através da solução eShopOnWeb. A ideia 
é que possamos extrair informações como o total financeiro em 
pedidos realizados dentro de uma hora, um dia ou um mês, por 
exemplo. 


Vamos aplicá-la à classe que implementa o serviço de pedidos 
( orderservice.cs ) presente no projeto ApplicationCore. 


Assim como no exemplo anterior, faremos a injeção do 
TelemetryClient no construtor da classe orderService.cs . 


public OrderService(IAsyncRepository<Basket> basketRepository, 
IAsyncRepository<CatalogItem> itemRepository, 
IAsyncRepository<Order> orderRepository, 


IUriComposer uriComposer, 
TelemetryClient telemetryClient) 


_orderRepository = orderRepository; 
_uriComposer = uriComposer; 
_basketRepository = basketRepository; 
_itemRepository = itemRepository; 
_telemetryClient = telemetryClient; 





E fazemos a chamada do método TrackMetric no método 


CreateOrderAsync : 


public async Task CreateOrderAsync(int basketId, 
Address shippingaddress) 


var order = new Order(basket.BuyerId, shippingAddress, items); 
await _orderRepository.AddAsync(order); 


double orderTotal = Decimal. ToDouble(order.Total()); 


_telemetryClient.TrackMetric("Total Orders Value", orderTotal) ; 
} 





Como exemplo, simulamos a realização de quatro pedidos: 


My Order History 


ORDER NUMBER DATE TOTAL STATUS 

1 10/23/2020 2:57:02 PM -03:00 $ 8.50 Pending Detail 
2 10/23/2020 2:57:15 PM -03:00 $19.50 Pending Detail 
3 10/23/2020 2:57:32 PM -03:00 $ 8.50 Pending Detail 
4 10/23/2020 2:57:43 PM -03:00 $ 8.50 Pending Detail 





Figura 7.15: Pedidos realizados. 


E através do portal do Azure conseguimos visualizar os valores 
enviados: 


1 customMetrics 
2 | where name == "Total Orders Value” 
3 


Resultados Gráfico UU colunas ©) Exibir hora (UTC-03:00) 


Concluído. Mostrando os resultados de última hora. 


> 23/10/2020 14:57:02.138 Total Orders Value 8,5 1 
> 23/10/2020 14:57:15.842 Total Orders Value 19,5 1 
> 23/10/2020 14:57:32.158 Total Orders Value 85 1 
> 23/10/2020 14:57:43.097 Total Orders Value 8,5 1 


Figura 7.16: Métricas dos pedidos realizados com uso do TrackMetric. 
GetMetric 


Uma alternativa ao método Trackmetric é a coleta de dados através 
do método Getmetric . A diferença para o método Trackmetric é que O 
envio dos dados para o Application Insights é reduzido, pois existe a 
consolidação dos dados antes do envio. Podemos verificar isso 
neste exemplo: 


Realizamos quatro simulações de compra, em momentos diferentes, 
na nossa aplicação de exemplo eShopOnWeb: 


[Spies 
My Order History 


ORDER NUMBER DATE 


10/23/2020 12:18:05 PM -03:00 
10/23/2020 12:18:31 PM -03:00 
10/23/2020 12:18:40 PM -03:00 
10/23/2020 12:18:53 PM -03:00 


ow No ~ 


Figura 7.17: Pedidos realizados. 


Agora, se observarmos como os dados são enviados, podemos 


TOTAL 


$ 12.00 
$ 8.50 
$ 12.00 
$ 8.50 


demouser@microsoft.com v 


STATUS 


Pending 
Pending 
Pending 
Pending 


Detail 
Detail 
Detail 
Detail 


e 


verificar que isso é feito de forma consolidada, reduzindo o número 
de envios e tráfego de dados, e evitando assim um potencial gargalo 


no fluxo das informações. 


1 customMetrics 


2 | where name == “Total Orders Value” 


3 


Resultados Gráfico 


O Colunas 


(©) Exibir hora (UTC-03:00) 


Concluído. Mostrando os resultados de última hora. 


> 23/10/2020 12:18:05.000 


Total Orders Value 


41 


Figura 7.18: Métricas dos pedidos realizados com uso do GetMetric. 


Nossa implementação ficou assim com o uso do método cetmetric : 


public async Task CreateOrderAsync(int basketId, 
Address shippingAddress) 


await _orderRepository.AddAsync(order) ; 


double orderTotal = Decimal.ToDouble(order.Total()); 


_telemetryClient.GetMetric("Total Orders Value") 
. TrackValue(orderTotal1) ; 





Para os demais envios, o valor é atualizado no Application Insights? 
A resposta aqui é não, os valores são consolidados a cada minuto e 
enviados. Os dados anteriormente enviados não são afetados. 


> 23/10/2020 12:18:05.000 Total Orders Value 41 


+ 23/10/2020 13:04:01.000 Total Orders Value 8,5 


Figura 7.19: Novas métricas inseridas após um minuto com uso do GetMetric. 
TrackException 


Através do SDK podemos também monitorar as exceções ocorridas 
em nossa aplicação. Por padrão, a coleta de exceções é habilitada 
junto à instrumentação de nossa aplicação. Podemos neste caso 
extender a funcionalidade e monitorar exceções em trechos 
específicos de código, dependências, scripts customizados, assim 


como outros cenarios. Para isso, fazemos uso do método 


TrackException . 


Caso exista falha no envio de e-mail de confirmação pela aplicação, 
vamos adicionar um tratamento para que possamos obter mais 
informações sobre o erro: 


try 
{ 
await _emailSender.SendEmailAsync(Input.Email, 
"Confirm your email", 


$"Please confirm your account by <a 
href='{HtmlEncoder.Default.Encode(callbackUr1)}'> clicking 


here</a>."); 


} 


catch (Exception ex) 


{ 


_telemetryClient.TrackException(ex); 


} 





Uma vez que coletamos essas informações podemos identificar 
onde os erros acontecem e a frequência com que são lançadas. 


TrackRequest 


TrackRequest permite que obtenhamos dados sobre as requisições 
enviadas por nossa aplicação. Uma requisição, diferente de um 
pageview , é referente a um recurso sendo solicitado entre cliente e 
servidor. Este recurso pode ser uma imagem (.jpeg, .gif), um script, 
uma página, um serviço, assim como uma variedade de outros 
recursos. 


Customizar a coleta de requisições através do uso do método 
TrackRequest possibilita correlacionar traces e acessar dependências 
através de um contexto de operação ( operationName ). Desse modo, 


todos os itens de monitoração coletados com esse nome pertencem 
ao mesmo contexto. 


Exemplo de uso: 


using (var operation = 
telemetryClient.StartOperation 
<RequestTelemetry>("“operationName" ) ) 


telemetryClient.TrackTrace(...); 


telemetryClient.StopOperation(operation) ; 





TrackTrace 


E se você precisa saber como é realizada a navegação ou a 
sequência de métodos executados pelo cliente para realizar um 
pedido? Para esses casos, podemos usar o método TrackTrace . Seu 
objetivo é colocar algumas marcações em nosso código para 
identificar sequências de eventos executados. 


No exemplo a seguir, vamos combinar os elementos do TrackRequest 
com O TrackTrace para demonstrar como eles podem ser usados. 
Para isso, efetuaremos uma alteração no processo de registro de 
um novo usuário para a aplicação. 


O arquivo onde está implementado o processo de registro é o 
Register.cshtml.cs € O método é O onPostasync . Adicione um trace 
logo após o token de confirmação ser gerado: 


var code = await 


_userManager.GenerateEmailConfirmationTokenAsync (user) ; 


var callbackUrl = Url.Page("/Account/ConfirmEmail", 
pageHandler: null, 
values: new { userId = user.Id, code = code }, 
protocol: Request.Scheme); 


_telemetryClient.TrackTrace( 
String.Format("Token de confirmação gerado para {0}", 
Input.Email) ); 





Após o envio do e-mail de confirmação: 


await _emailSender.SendEmailAsync(Input.Email, 

"Confirm your email", 

$"Please confirm your account by <a 
href='{HtmlEncoder.Default.Encode(callbackUr1)}'> clicking 
here</a>."); 


_telemetryClient.TrackTrace( 
String.Format("Envio de e-mail de confirmação para {0}", 
Input.Email)); 





E após ser autenticado pela primeira vez, após o cadastro: 


await _signInManager.SignInAsync(user, isPersistent: false); 
_telemetryClient.TrackTrace( 


String.Format("Primeiro signin efetuado por {0}", 
Input.Email)); 





Para que possamos colocar todos dentro do mesmo contexto, 
vamos criar a estrutura necessaria para encapsular cada um desses 
itens: 


using (var operation = _telemetryClient 
.StartOperation<RequestTelemetry>("Processo de registro") ) 


_telemetryClient.TrackTrace( 
String.Format("Token de confirmação ..."); 


_telemetryClient.TrackTrace( 
String.Format("Envio de e-mail de confirmação para {0}", 
Input.Email)); 


_telemetryClient.TrackTrace( 
String.Format("Primeiro signin efetuado por {0}", 
Input.Email)); 


_telemetryClient.StopOperation(operation) ; 
} 





Podemos observar o registro dos traces no portal do Azure através 
do recurso de pesquisa da transação: 


Transação de ponta a ponta 
ID da Operação: 4c6dda342735cc47ba763757d02931e9 © 


6 Todos; 3 Rastreamentos; 0 Eventos; Exibir linha do tempo bi 


Filtrar para um componente e uma chamada específicos 


Tudo [Componente | Chamada] v 


É, REQUEST 01:15:16.493 | localhost:44315 


POST /Account/Register 


E, REQUEST 01:15:16.575 | 


Processo de registro 











=| TRACE 01:15:16.583 | 





Token de confirmação gerado para teste@1@teste.com.br 


ENVIO DE E-MAIL 01:15:16.588 | 





=| TRACE 01:15:16.588 | 





Envio de e-mail de confirmação para teste@1@teste.com.br 











=| TRACE 01:15:16.824 | 


Primeiro signin efetuado por teste@1@teste.com.br 


Figura 7.20: Transação realizada de ponta a ponta. Uso do TraceRequest. 
TrackDependency 


Conforme desenvolvemos nossa aplicação percebemos que ela não 
funciona de forma isolada. Ela possuirá dependências, seja de 
componentes presentes em sua arquitetura, seja de recursos 
externos como bancos de dados e serviços. 


Para esses componentes externos, o SDK do Application Insights 
permite avaliar o quanto eles influenciam na performance de nossa 
aplicação. Por exemplo, podemos investigar o total de tempo 
demandado por uma consulta (executada em banco de dados) que 
é sempre executada quando requisitamos uma determinada página 
de nossa aplicação. 


Essa monitoração pode ser customizada através do método 
TrackDependency . No exemplo a seguir, aplicamos o uso do método 
TrackDependency € deste modo visualizamos quanto tempo é 
necessário para enviar o e-mail de confirmação. 


var success = false; 
var startTime = DateTime.UtcNow; 
var timer = System.Diagnostics.Stopwatch.StartNew() ; 


try 
{ 
await _emailSender.SendEmailAsync(Input.Email, 
"Confirm your email", 
$"Please confirm your account by <a 
href='{HtmlEncoder .Default.Encode(callbackUrl)}'> clicking 
here</a>."); 


success = true; 


} 


catch (Exception ex) 


{ 


} 
finally 


{ 


_telemetryClient.TrackDependency( 

"Envio de e-mail", 

" emailSender", 
"SendEmailAsync", 
startTime, 
timer.Elapsed, 


success); 





7.3 Resolvendo problemas com o Application 
Insights 


Já vimos que o Application Insights pode ser utilizado para dar 
visibilidade de diversos aspectos das aplicações através de 


métricas, provendo uma visão estratégica de pontos ou 
funcionalidades a serem aperfeiçoadas, o que consideramos como 
ações proativas e preventivas. 


Por outro lado, essa ferramenta também é muito poderosa na 
identificação de problemas em aplicações. Ela pode fornecer 
informações e histórico de fatos que são imprescindíveis para uma 
análise de causa raiz eficaz. 


Para que essas análises sejam realizadas, a ferramenta 
disponibiliza duas visões que são agnósticas a plataformas de 
desenvolvimento (.NET, Java, Node.js etc.) e a sistemas 
operacionais (Linux, Windows, MacOs etc.): 


e Falhas (Failures): temos a visão de todos os erros que 
aconteceram na aplicação, com informações relevantes para a 
identificação da causa. Alguns exemplos são: tipo do erro, 
mensagem, local onde ocorreu e até mesmo a linha de código 
de origem. 


e Performance: temos informações detalhadas do tempo gasto 
para executar diversas ações dentro da aplicação e também de 
suas dependências. Como exemplo: HTTP, cache, banco de 
dados, mensagerias, envio de e-mail. 


Análise de performance 


Na visão de performance, é possível ver a média de tempo 
(duration) e o total de execuções (count) das operações, que, para 
uma aplicação web, são consideradas as requisições HTTP por 
padrão. 


Além da visão consolidada, podemos analisar as requisições de 
forma individualizada com os detalhes de tempo das chamadas de 
dependências que ocorreram. As dependências monitoradas 
automaticamente por padrão são: HTTP/HTTPS, WCF, SQL, Azure 
Storage, EventHub e ServiceBus. Porém, como vimos 
anteriormente, é possível criar monitoração de dependência 


customizada através do TrackDependecy e, nesses casos, elas 
também aparecem no detalhamento. 


Select operation O Search to filter items 


OPERATION NAME DURATION (AVG) + COUNT PIN 


| Overall A ms peo 


GET /images/products/4.png e ms 42 
GET /images/products/1.png nos ms 44 
GET /images/main banner text.png ER ms 51 
GET /images/brand.png as ms 90 
GET /images/cart.png 5 5 ms 90 
GET /favicon.ico 14.3 ms 49 





Figura 7.21: Visão da performance das operações (requisições). 


Ao selecionar como exemplo a operação GET /Index da imagem 
anterior e clicar em Amostras (Samples), podemos ver as operações 
capturadas individualmente e clicar em cada uma delas para obter 
detalhes do tempo consumido com suas dependências. 


End-to-end transaction 


Operation ID: a89743b98a504C30be5ee43eb678c52c d Create work item 
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Figura 7.22: Detalhes da performance da operação (requisição). 


Na imagem anterior, podemos ver que a operação levou 2.2 
segundos e dentro desse tempo tivemos 4 execugoes no banco de 
dados (dependéncias), conforme a seguir: 


Execução Tempo 

1 119 ms 

2 118 ms 

3 920 ms 

4 1000 ms (ou 1s) 
Total 2157 ms (ou 2.1s) 


Nesse exemplo, o tempo da operação total (2.25) foi muito 
semelhante à soma de todas as suas dependências (2.1s). Este é 
um caso em que para melhorarmos (reduzirmos) o tempo dessa 
operação, provavelmente precisaremos otimizar o acesso de suas 
dependências ao banco de dados. Para nossa facilidade, o 
Application Insights também traz o comando SQL executado em 
cada uma das chamadas ao banco de dados ao clicar na 
dependência e observar o campo command . 


» 
+ Create work item 


E sql-eshoponweb-ch-001 
Microsoft.eShopOnWeb.CatalogDb 


Dependency Properties Show all 
Event time 10/26/2020, 6:48:52 PM (Local time) 
Dependency type SQL 


Dependency call status true 
Dependency duration 119 ms 


Remote dependency SQL: tcp:sql-eshoponweb-ch- 
name 001.database.windows.net, 1433 | 
Microsoft.eShopOnWeb.CatalogDb 


Custom Properties 


AspNetCoreEnvironme Production 
nt 


Command D Copy 


SELECT [c].[Id], [c].[CatalogBrandId], [c].[CatalogTypeId], [c]. 
[Description], [c].[Name], [c].[PictureUri], [c].[Price] 

FROM [Catalog] AS [c] 

WHERE [c].[Id] IN (3) 


Figura 7.23: Detalhes da execução da dependência SQL. 


Para concluir, neste cenário, ao otimizar a execução dessas 
consultas SQL no banco de dados, teremos um reflexo direto na 
otimização da operação (requisição), resultando em uma melhor 
experiência para os usuários da aplicação. 


COMO HABILITAR A RASTREABILIDADE DE COMANDOS SQL? 


A captura de comandos SQL nao vem habilitada por padrao no 
Application Insights. Para habilita-la, recomendo seguir a 
documentação do produto. 


https://docs.microsoft.com/azure/azure-monitor/app/asp-net- 
dependencies#advanced-sql-tracking-to-get-full-sql-query 





Existem casos diferentes do exemplo anterior, no quais o tempo 
total da requisição não está relacionado ou não é justificado por 
suas dependências mapeadas. De modo geral, quando essa 
situação ocorre, o tempo da requisição pode estar relacionado a 
duas origens não capturadas automaticamente pelo Application 
Insights: 


e Execução de código: o tempo gasto (performance) na 
execução de códigos e algoritmos da aplicação não é capturado 
por padrão. Para ter essa informação, é necessário utilizar uma 
funcionalidade chamada Profiler do Application Insights. 


e Dependências (não mapeadas): podem existir muitas 
dependências nas aplicações que não são automaticamente 
mapeadas pelo Application Insights e, nesse caso, cabe aos 
desenvolvedores dessa aplicação incluir a monitoração das 
dependências de forma customizada, como explicado em 
detalhe na seção sobre O TrackDependency . Alguns exemplos de 
dependências não mapeadas por padrão são: envio de e-mail 
(SMTP), acesso a compartilhamento de arquivos (NFS/SMB), 
acesso a serviços de FTP e outros protocolos menos 
comumente utilizados em cima dos protocolos TCP e UDP. 


Com o uso do Profiler e o mapeamento de dependências 
customizadas, tudo será automaticamente agregado à operação 
(requisição) e será possível ter um maior e melhor detalhamento do 
tempo gasto em cada etapa. 


A seguir temos o exemplo da inclusão do mapeamento de uma 
dependência customizada (envio de e-mail) para o envio de e-mail, 
que foi realizada na seção sobre o uso do TrackDependency deste 
capítulo. Podemos ver a informação gerada após uma requisição 
realizada. 
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End-to-end transaction 
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Figura 7.24: Exemplo de mapeamento de dependéncia customizada (e-mail). 


Também é possível ver os traces e os eventos gerados 
(customizados Ou não) através do TrackTrace € TrackExeception 
associados a essas requisições clicando no view all telemetry . 


(i) Welcome to the new correlation experience in Application Map and Transaction Details. If you prefer the old experience, click "Leave preview” above to return to it. 


End-to-end transaction 
Operation ID: 4c6dda342735cc47ba763757d02931e9 E 


Da Eire O Events: View timeline \/ 


Filter to a specific component and call 





| All [Component | Call] v | 





E, REQUEST 1:15:16.493 AM | localhost:44315 


POST /Account/Register 


É, REQUEST 1:15:16.575 AM | 


Processo de registro 


[E] TRACE 1:15:16.583 AM | 


Token de confirmação gerado para teste@1g@teste.com.br 
ENVIO DE E-MAIL 1:15:16.588 AM | 

[E] TRACE 1:15:16.588 AM | 

Envio de e-mail de confirmação para testeGlgteste. com.br 


[E] TRACE 1:15:16.824 AM | 


Primeiro signin efetuado por teste@1@teste.com.br 


Figura 7.25: Visão dos traces e eventos associados à operação. 
Profiler 


Com o uso do Profiler, é possível obter a performance ou tempo 
gasto na execução de códigos internos e algoritmos da aplicação. 
Ele utiliza uma combinação de amostragem (sampling) e 
instrumentação (instrumentation) para gerar as informações de 
performance detalhadas. Dessa maneira, o custo (impacto) de 
performance ao habilitar o Profiler para as aplicações é baixo. 


Porém, o Profiler não é habilitado por padrão durante toda a vida de 
execução da aplicação como no caso da monitoração das 
operações e dependências. Ele é uma ferramenta de uso em 
ambiente produtivo que deve ser habilitado somente no momento 
em que desejar a coleta de informações detalhadas de performance 
para investigação. Ele pode ser acionado manualmente ou então 
iniciado automaticamente com base no consumo de CPU ou na 
memoria da aplicação. 


Home > appi-eshoponweb > 


Configure Application Insights Profiler & 


ZO Triggers ©) Refresh 4? Troubleshoot profiler 


Triggered By 


App Name 


pera 
Recent profiling sessions AC ionamento M anu al 
(Click on a row to open traces) 


Triggered By 





Ty App Name 
No application has reported a profiling session. Try use 'Profile now' to trigger one. 


Figura 7.26: Acionamento manual do Profiler. 


Trigger Settings 


~ 


Acionamento por 
CPU Trigger © CPU ou 
em d Memoria 





EO Learn more 








CPU Threshold (9%) © 





80 





Profiling Duration © 


Time : 120 Seconds 


Cooldown © 


Time: 4 hrs 


Figura 7.27: Acionamento automático do Profiler por uso de CPU ou memória. 


Para ambos os casos, após o acionamento do Profiler, a coleta tem 
duração padrão de 20 minutos. Dessa forma, após iniciar a coleta, é 
necessário que sejam realizados acessos à aplicação, ou que seja 
reproduzido o cenário de problema de performance (a ser 
investigado) dentro dessa janela de tempo para que, após a coleta, 
possamos avaliar o tempo gasto em cada trecho de código da 
aplicação de forma detalhada. 


Normalmente o Profiler é utilizado para analisar os trechos de 
códigos que são mais acionados (hot path), exibindo o tempo de 


execução e a quantidade de CPU gasta em cada método da 
chamada. 


A seguir temos um exemplo visual de como se parece uma coleta 
do Profiler de uma aplicação para análise. 
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Figura 7.28: Coleta do Profiler. 


Maiores detalhes do uso do Profiler podem ser encontrados na 
documentação. 


https://docs.microsoft.com/azure/azure-monitor/app/profiler- 
overview 





Portanto, o uso das funcionalidades fornecidas no Application 
Insights, de acordo com a necessidade de nossas aplicações, pode 
oferecer uma visão ampla, robusta e que com toda certeza vai 


contribuir para definir as prioridades de desenvolvimento e 
solucionar problemas rapidamente em nossas aplicações e 
produtos. Essas funcionalidades contribuem para termos aplicações 
com foco nos usuários, fornecer uma experiência incrível e 
confiável, além de ajudar a definir um caminho de evolução para a 
aplicação que faça sentido para os usuários e para o negócio. 


Análise de erros e exceções 


O painel de falhas (failures) nos dá uma visão dos erros ocorridos 
na aplicação e todos os detalhes para encontrar a causa do 
problema. 


iy appi-eshoponweb | Failures 2 
o 
































users 





Figura 7.29: Visão principal do painel de falhas do Application Insights. 


Temos diversas visões que podemos utilizar para um melhor 
entendimento dos erros e o impacto que estão causando para a 
aplicação e os usuários. 


O gráfico principal nos mostra os erros ocorridos no decorrer do 
tempo. Para uma aplicação web são considerados erros os retornos 
HTTP com status 4xx e 5xx. Ao lado direito superior da imagem 
anterior, podemos ver os erros agrupados por retorno HTTP 
chamado de Top 3 response codes. 


Além dos erros exibidos por retorno HTTP, temos uma visão (lateral 
direita) chamada de Top 3 exception types, que nos fornece uma 
visão das exceções que ocorrem na aplicação, independentemente 
de terem gerado um retorno HTTP 5xx/4xx ou não. 


Por último, temos uma visão das dependências que mais causaram 
erros dentro do período analisado, chamada de Top 3 failed 
dependencies. 


É importante entendermos o resumo apresentado sobre painel de 
falhas, pois os erros em aplicações podem não estar relacionados e 
precisamos das distinções dos tipos de erros (exceções, erros HTTP 
e dependências) para analisar e encontrar sua causa. 


Para deixar esse cenário mais claro, vamos colocar as seguintes 
afirmações: 


e A aplicação responde uma requisição com status HTTP 
500, pois foi gerada uma durante o acesso ao banco de 
dados que estava em estado de falha (falha em 
dependência). Nessa afirmação, analisando a operação em 
falha (requisição HTTP), provavelmente teremos uma exceção 
vinculada e relacionada ao acesso da dependência externa 
(banco de dados). 


e A aplicação responde uma requisição com status HTTP 
500, porém não houve nenhuma exceção interna ou 
problema em acesso de dependência. Essa situação pode 
ocorrer por diversas razões. Por exemplo, definir o status HTTP 
5xx de retorno de acordo com alguma lógica da aplicação. 


Conhecer essas duas situações nos ajudam a entender o 
relacionamento entre erros, com base em retornos HTTP, de 
exceções e erros de dependências. 


A primeira afirmação normalmente acontece em cenários em que é 
mais simples encontrar a causa do problema, pois temos um erro de 
retorno HTTP 5xx associado a uma exceção no código, que é 


capturada e exibida em detalhes pelo Application Insights. Ja na 
segunda afirmação, como não é gerada uma exceção na aplicação 
e apenas o retorno HTTP é de erro 5xx, não existe um evento a ser 
capturado automaticamente pelo Application Insights, porque pode 
ser apenas uma lógica definida na aplicação, dificultando a análise 
de causa do problema. 


A seguir, veremos um exemplo relacionado à primeira afirmação, 
onde o retorno da requisição HTTP foi 500 e internamente na 
aplicação ocorreu um erro de acesso ao banco de dados (SQL). 
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Figura 7.30: Detalhes da requisição com erro. 


Clicando em cada uma das Exception podemos ver diversos 


detalhes, como operação executada, mensagem, tipo da exceção e 
o local onde ocorreu. 


E sql-eshoponweb-ch-001 
Microsoft.eShopOnWeb.CatalogDb 


Dependency Properties Show all 
| Event time 10/26/2020, 6:36:50 PM (Local time) 
Dependency type SQL 
Dependency call status false 
Dependency duration 1.25 
Remote dependency SQL: tcp:sql-eshoponweb-ch- 
name 001.database.windows.net, 1433 | 
Microsoft.eShopOnWeb.CatalogDb 
Custom Properties 
AspNetCoreEnvironme Production 
nt 
Exception System.AggregateException: One or more errors 
occurred. (The server principal “eshopweb” is not 
able to access the database 
"Microsoft.eShopOnWeb.CatalogDb" under the 
current security context. Cannot... [show more] 
Command D Copy 
OpenAsync 


Figura 7.31: Falha na execução da dependência SQL. 


Nesse caso, vemos que a aplicação tentou executar um comando 
de OpenAsync com o banco de dados e recebeu uma exceção com 
a mensagem de que não foi possível acessar a base de dados por 


falha de login: ( The server principal eshopweb is not able to access the 
database Microsoft.eShopOnWeb.CatalogDb under the current security 


context. Cannot open database Microsoft.eShopOnWeb.CatalogDb requested by 
the login. The login failed. Login failed for user eshopweb. b 


Além da mensagem, podemos ver qual seção do código da 
aplicação tentou acessar o banco de dados quando o erro ocorreu. 


Call Stack Just my code D Copy | Expand 


Microsoft.Data.SqlClient.SqlException: 

at Microsoft.Data.ProviderBase.DbConnectionPool.CheckPoolBlockin 
at Microsoft.Data.ProviderBase.DbConnectionPool.CreateObject (Mi 
at Microsoft.Data.ProviderBase.DbConnectionPool .UserCreateReques 
at Microsoft.Data.ProviderBase.DbConnectionPool.TryGetConnection 
at Microsoft.Data.ProviderBase.DbConnectionPool.WaitForPendingOp 
at System. Runtime. ExceptionServices .ExceptionDispatchInfo.Throw 
at System. Runtime.CompilerServices.TaskAwaiter.ThrowForNonSucces 
at System.Runtime.CompilerServices.TaskAwaiter.HandleNonSuccessA 
at Microsoft.EntityFrameworkCore.Storage.RelationalConnection+<0 
at System. Runtime. ExceptionServices.ExceptionDispatchInfo. Throw 
at Microsoft.EntityFrameworkCore.Storage.RelationalConnection+<0 
at System. Runtime. ExceptionServices.ExceptionDispatchInfo.Throw 
at System. Runtime.CompilerServices. TaskAwaiter.ThrowForNonSucces 
at System.Runtime.CompilerServices.TaskAwaiter.HandleNonSuccessA 
at Microsoft.EntityFrameworkCore.Storage.RelationalConnection+<0 v 


d 


Figura 7.32: Call stack da chamada que retornou o erro. 


Nesse caso, através das informações capturadas e fornecidas pelo 
Application Insights, podemos afirmar de uma forma simples que a 
causa do problema não está na aplicação e sim na credencial 
utilizada para acessar o banco de dados. 


7.4 Resumo 


Neste capítulo, conseguimos abordar a utilização do Application 
Insights para o monitoramento de uma aplicação: 


e Descrevemos a importância de monitorarmos uma aplicação 
alinhada com a estratégia do produto. 

e Vimos como podemos obter de forma rapida os beneficios do 
monitoramento através da utilização do SDK do Application 
Insights. 

e Vimos como é possível customizarmos a coleta de informações 
em pontos estratégicos de uma aplicação. 

e Por último, como utilizamos as informações do Application 
Insights para o diagnóstico de problemas de uma aplicação. 


No próximo capítulo, vamos validar a qualidade da nossa aplicação 
adicionando todo o processo de testes. 


CAPITULO 8 
Testes & QA 


Escrito por Augusto Araujo, Beatriz Matsui, Eric Shimokawa e 
Fernando Henrique Inocéncio Borba Ferreira. 


CENARIO 


A aplicagao esta evoluindo. Além das features ja desenvolvidas, 
no capitulo anterior, foram adicionados recursos que 
possibilitaram o monitoramento dessa aplicação. Após essas 
alterações, como podemos validar as funcionalidades? Como 
garantir que a aplicação não contém bugs e que está com uma 
boa qualidade”? 


Testes são a melhor forma para responder a essas questões e 
nos dar a confiança para codificarmos com muito mais 
segurança. Com eles, sabemos que não estamos quebrando 


funcionalidades já entregues, e que o que estamos 
desenvolvendo está de acordo com a expectativa e com a 
qualidade esperada. 


Neste capítulo, vamos abordar a importância dos testes no 
desenvolvimento do software e detalhar técnicas recomendadas, 
tais como: 


e Testes exploratórios. 
e Testes de unidade. 





8.1 Importância dos testes 


Por que devemos testar um software? 


Simplesmente porque somos humanos e seres humanos cometem 
erros. Pequenos erros cometidos no desenvolvimento de software 
podem resultar em enormes prejuizos. 


Como exemplo, podemos citar a famosa história da sonda espacial 
Mars Climate Orbiter projetada pela NASA. O objetivo dessa sonda 
era pousar em Marte para realizar estudos climáticos deste planeta. 
Contudo, o MCO foi destruído na atmosfera de Marte devido a um 
simples erro de cálculo. A manobra de inserção orbital foi realizada 
em uma altitude errada devido à utilização do sistema de unidade 
errada. A equipe de comando da terra realizou os cálculos utilizando 
a unidade imperial, entretanto a sonda espacial trabalhava com 
unidade métrica. Dessa forma, as informações passadas foram 
equivocadas e a sonda não teve tempo e força o suficiente para 
realizar a frenagem, colidindo com o planeta. Esse erro custou 
centenas de milhões de dólares de prejuízo para a NASA. Após 
investigações, concluíram que o maior responsável por esse 
desastre foi a falta de um maior controle de qualidade. Simples 
testes de software poderiam ter evitado essa tragédia. 


Testar software é uma forma de verificar a qualidade do que foi 
desenvolvido, reduzindo o risco de encontrarmos falhas quando o 
sistema estiver em operação, e de confirmar que o que 
desenvolvemos é realmente o que nos comprometemos a entregar. 


Quando compramos um carro, um celular, um videogame, 
esperamos que eles funcionem corretamente, que as 
funcionalidades que nos foram apresentadas e que motivaram 
nossa compra sejam compatíveis com o que esperávamos, com a 
nossa expectativa. 


Imagine se, ao tentarmos ligar o carro, ele não funcionasse ou se o 
motor parasse de funcionar logo depois de rodar poucos quilômetros 
fora da concessionária. Imagine que você não consiga realizar uma 


simples ligagao com seu celular ou que o seu videogame trave toda 
vez que você está começando a se empolgar na partida? 


Essas experiências podem ser muito frustrantes para o comprador, 
resultando em custos elevados para a empresa responsável pelo 
desenvolvimento do produto, sejam em forma de prejuízo financeiro, 
devido a uma indenização ou substituição do produto com defeito, 
sejam em forma de prejuízo para sua reputação, o que acontece 
quando o cliente perde a confiança em sua marca e passa a utilizar 
os produtos do concorrente. O prejuízo pode ser ainda maior se a 
falha do produto em questão significar vida ou morte. Sistemas e 
equipamentos médicos, controladores de aviões ou até mesmo o 
sistema de ejeção de um airbag, se mal projetados e mal testados, 
podem levar à morte. 


Indisponibilidade de sistemas também é responsável por prejuízos 
enormes. Nos dias de hoje, é simplesmente inadmissível um 
sistema de conta corrente ou internet banking ficar indisponível por 
dias ou até mesmo por apenas algumas horas. 


Sabendo de tudo isso, por que constantemente não damos 
prioridade aos testes ou até mesmo os deixamos de lado? 


Os principais motivos para justificar a falta de testes são o prazo e o 
orçamento. Estimativa de software é uma arte complexa e fácil de 
errar. E, quando o prazo começa a apertar, a primeira coisa que 
removemos são as atividades de qualidade. Ficamos focados 
apenas em entregar a funcionalidade, do jeito que for, no prazo 
estipulado. 


Se esses forem os motivos para não realizar os testes, nós, como 
desenvolvedores ou testadores, não temos muito o que fazer. Os 
testes são fundamentais para a garantia de qualidade do produto 
que será entregue, mas realmente demandam consideráveis 
recursos e custos. Se os gestores não enxergarem o valor dos 
testes e não provisionarem os recursos necessários, a implantação 
dos testes não será efetiva. Para esses casos, seria necessária toda 


uma mudança cultural e de percepção da empresa, o que não é 
fácil. 


Outro grande motivo para o abandono dos testes é o sentimento de 
dificuldade da implantação dos testes em metodologia ágil. Cria-se 
uma equipe de QA, responsável por todo um processo de testes, 
criação de plano de testes, casos de testes, testes de aceitação, 
testes regressivos, gerando um enorme esforço. Esse esforço torna- 
se muito maior que a sprint e, devido à falta de documento de 
especificação das funcionalidades, todo esse insumo gerado acaba 
não se encaixando com o que foi entregue pelo time de 
desenvolvimento. 


A agilidade mudou a forma como desenvolvemos sistemas. Não 
passamos mais meses tentando descobrir e especificar tudo o que 
achamos que precisa ser desenvolvido. Agora temos que realizar 
entregas menores, mas já agregando valor ao cliente, em curtíssimo 
espaço de tempo. 


Se houve uma enorme mudança na forma como desenvolvemos 
software, por que não devemos também mudar a forma como 
realizamos os testes? A resposta é que devemos, sim, mudar a 
forma como os testes são planejados e executados, inclusive 
existem hoje diversos estudos e técnicas de testes ágeis e é um 
pouco desses conceitos que desejamos passar para vocês neste 
capítulo. 


Na metodologia waterfall, existem fases bem definidas e passamos 
para a próxima fase apenas quando a anterior for totalmente 
concluída, como podemos ver na figura a seguir. 









* Entendimento do que devemos construir 


Requisito * Documento de requisitos 


* Especificação dos requisitos de sistema e hardware 


Design * Arquitetura 


Implementação 






* Codificação do sistema 


* Testes 
* Qualidade 
* Validação dos requisitos 








Verificação 


* Implantação no ambiente produtivo 


Implantação * Liberação do produto para o mercado 


* Monitoração do sistema e ambiente 


Manutenção * Correção de defeitos 


Figura 8.1: Metodologia Waterfall. 


Com essa metodologia, sistemas grandes ou complexos 
costumavam demorar meses ou anos para serem entregues e 
podemos observar que a fase de testes ocorria quase no final do 
processo, somente após todo o sistema já ter sido codificado. Com 
isso, a equipe de testes possuía um tempo enorme para realizar 
todo o planejamento dos testes. Recebiam especificações 
completas do projeto e a partir delas realizavam todo o 
planejamento e especificação dos testes. Casos de testes eram 
criados para cada uma das funcionalidades a serem entregues, 
planos de testes e cronogramas eram apresentados aos gestores. 
Finalmente, os testes eram executados em uma data prevista com 
todo o desenvolvimento já realizado e entregue. 


Com a chegada das metodologias ágeis, houve uma grande 
mudança na forma como desenvolvemos sistemas. As empresas 
não conseguem mais suportar projetos que exijam um longo tempo 
de espera. Vivemos agora em um mundo extremamente competitivo 
que exige constante aprimoramento e mudança. Uma nova 
funcionalidade ou até mesmo uma pequena melhoria no sistema 
que proporcione uma melhor experiência ao usuário pode ser a 
diferença entre uma empresa e o concorrente. Se esperássemos 
meses ou anos para publicar uma nova funcionalidade, enquanto 
nosso concorrente implementa melhorias e novas funcionalidades a 


cada semana, com certeza nosso negocio estaria fadado ao 
fracasso. 


Com a popularização dos conceitos de DevOps, essa mudança se 
tornou ainda maior. Conforme a pesquisa Accelerate: State of 
DevOps 2019, realizada anualmente pela DORA (DevOps Research 
& Assessment), as empresas que foram classificadas como elite 
trabalham incessantemente para entregar cada vez mais e melhor, 
conseguindo realizar multiplos deploys diariamente. 


Aspect of Software Delivery Performance* High Medium Low 










Between once Between once Between once 

per day and per week and per month and 
once per week once per month once every six 

months 


On-demand 
(multiple 
deploys per day) 





Less than Between one Between one Between one 
one day day and week and month and 
one week one month six months 


Less than Less than Less than Between one 
one hour one day? one day? week and 
one month 


0-15%>< 0-15%>* 0-15%*" 46-60% 


Figura 8.2: Accelerate: State of DevOps 2019 por DORA. 


NOTA 


Veja o relatorio completo no link a seguir: 
https://cloud.google.com/devops/state-of-devops 





Tendo em vista multiplos deploys diarios, temos tempo habil para 
realizar todos os nossos testes de QA e garantir a entrega da 
funcionalidade com a qualidade esperada? 


A cada ciclo de entrega, novas funcionalidades sao incorporadas, 
tornando o sistema cada vez mais complexo. Se nao tivermos um 
bom planejamento de qualidade e testes adequados, sera cada vez 
mais dificil entregar uma nova funcionalidade sem quebrar outras. 


Entretanto, parece totalmente inviavel conseguirmos liberar a 
funcionalidade para o ambiente de testes, aguardar o time de QA 
realizar todos os procedimentos, aguardar a aprovação dos testes e 
finalmente realizar o deploy da funcionalidade em curtíssimos 
intervalos de tempo. 


Se desejamos ser ágeis e uma equipe de alto desempenho, não 
devemos mais pensar em testes da forma como trabalhávamos e 
devemos focar em testes ágeis. Precisamos de testes que sejam 
executados constantemente e de forma muito rápida e a resposta 
para isso é a automatização dos testes. 


A automatização dos testes pode ter um custo inicial mais elevado 
do que testes manuais, entretanto, uma vez criados, podemos rodá- 
los a qualquer momento, sem a necessidade de provisionar pessoas 
para a realização dos testes, o que gradativamente reduz a 
diferença de custos. Além disso, a criação dos testes, da mesma 
forma que o desenvolvimento do sistema, deverá ser feita de forma 
interativa e incremental, aumentando paulatinamente a quantidade e 
qualidade de testes executados. 


Outra vantagem da automatização dos testes é que, sempre que 
estamos executando esse conjunto de testes automatizados, 
estamos realizando testes regressivos, evitando que erros antigos 
voltem a ocorrer e que a entrada de novas funcionalidades quebre 
as já desenvolvidas e aprovadas. 


Quanto mais testes automatizados criamos, mais aumentamos a 
cobertura de código, reduzindo a probabilidade de encontrarmos 
erros em produção. Entretanto, não faz muito sentido criarmos uma 
infinidade de testes que demorem dias para serem executados se 
desejamos realizar deploys diariamente. Devemos focar em testes 


que sejam executados rapidamente, para que sejam executados 
com frequência e, consequentemente, descubramos os erros 
antecipadamente. 


Mike Cohn, em seu famoso livro Succeeding with Agile, apresentou 
o conceito da pirâmide de testes (Test Pyramid), que reflete 
exatamente a vantagem de focarmos em testes mais rápidos e de 
menor custo de desenvolvimento. Essa pirâmide foi adaptada por 
Martin Fowler, refletindo melhor as vantagens dos tipos de testes em 
relação a custo e velocidade de execução dos testes, conforme 
podemos ver na imagem a seguir: 


e $$$ 


unidade 


SP ¢ 


Figura 8.3: Piramide de testes. 


NOTA 


Para maiores detalhes da pirâmide, veja o artigo abaixo Test 


Pyramid de Martin Fowler: 
https://martinfowler.com/bliki/TestPyramid.html 





Segundo Mike Cohn, a piramide demonstra que a base dos testes 
automatizados é o teste de unidade. Este tipo de teste deve ser a 
fundação para uma estratégia sólida de testes automatizados e 
deve representar a maior parte da pirâmide. 


Testes de unidade são excelentes, pois são de fácil implementação, 
rápida execução e oferecem insumos preciosos para a pessoa que 
desenvolve, como o nome do método e até mesmo a linha do 
programa que gerou o erro. 


Ao contrário dos testes de unidade, os testes de interface devem ser 
usados com moderação, sendo desejável utilizar o mínimo possível, 
devido aos seguintes fatores: 


e Fragilidade: qualquer alteração na interface pode quebrar os 
testes, gerando retrabalho para consertá-los. 

e Execução lenta: testes de interface são pesados e, ao criarmos 
inúmeras suítes de testes de interface automatizados, a 
execução pode demorar horas ou até mesmo dias para finalizar. 

e Redundância: ao realizarmos os testes pela interface, o mesmo 
método da camada de serviço pode ser chamado em diversos 
lugares dessa interface, desperdiçando recursos e tempo ao 
testar o mesmo código. 


Ao realizarmos os testes diretamente na camada de serviço 
isolando a interface, evitamos os problemas acima, tornando o 
processo de testes muito mais eficiente, organizado e de menor 
custo. 


Neste livro, realizaremos diversas refatorações na aplicação, onde 
mudamos apenas a estrutura interna do código, aplicando boas 
práticas para facilitar a manutenibilidade do sistema. Serão 
realizadas mudanças na arquitetura da aplicação, por exemplo, ao 
desacoplarmos o front-end do back-end e ao transformar a 
aplicação em microsserviços. 


É fundamental possuirmos um conjunto de testes robustos antes de 
realizar essas refatorações, principalmente se o sistema já estiver 


rodando em ambiente produtivo, pois bugs e quebra de 
funcionalidades podem acontecer durante esse processo. 


E importante salientar que, apesar de falarmos sobre testes apenas 
neste capitulo, os testes devem ser realizados durante todo o ciclo 
de desenvolvimento da aplicagao. Devem ser planejados e 
desenvolvidos juntamente com o sistema e, assim como o 
desenvolvimento do sistema, o desenvolvimento dos testes também 
deverá ser realizado de forma iterativa e incremental, com entregas 
com valor agregado em cada uma das iterações. 


Técnicas muito conhecidas e recomendadas como TDD (Test-Driven 
Development) e ATDD (Acceptance Test-Driven Development) vão 
além e dizem que os testes devem ser realizados antes do 
desenvolvimento do sistema. 


As práticas de Shift Left Testing dizem para realizarmos os testes o 
quanto mais cedo possível e frequentemente. Se iniciarmos os 
testes até mesmo antes do desenvolvimento, testando insumos das 
fases de requisitos, design e arquitetura, por exemplo, podemos 
encontrar erros nas especificações dessas fases, evitando um 
enorme desperdício desenvolvendo algo que foi idealizado de forma 
equivocada. 





Shift Left 
Requisitos dea Testes 
Shift Left 
Design (= Testes 
Shift Left 
Codificação d Testes 
Shift Left 
Deploy (e be 


Figura 8.4: Shift Left Testing. 














Independente da técnica ou metodologia utilizada, ao antecipar, 
automatizar e executar os testes constantemente, alcançamos 
valiosos benefícios, dentre eles: 


e Feedback antecipado: quanto antes detectarmos erros, mais 
fácil será corrigi-los, pois saberemos exatamente quais 
mudanças geraram o erro e temos ainda fresco na memória o 
que realizamos. 

e Redução de custos: além da redução de custos na correção 
de bug através do feedback antecipado, com a automatização 
dos testes podemos obter redução de custos da estrutura de TI, 
reduzindo custos de staff, custos de execução e tempo de 
entrega dos testes, principalmente testes regressivos. 

e Maior eficiência: a automatização dos testes permite que 
executemos testes em um tempo bem menor e, 
consequentemente, que os executemos mais vezes. Permite 
ainda que novos testes sejam implementados e revisados 


gradativamente, melhorando cada vez mais a cobertura e 
eficiéncia. 

e Confiança: a automatização dos testes permite que tenhamos 
mais confiança na entrega de funcionalidades e na realização 
de refatorações, reduzindo o risco de introduzir novos bugs. 

e Qualidade: a soma dos benefícios acima resulta em entregas 
com muito mais qualidade e valor agregado ao sistema. 


Espero que esta introdução tenha de alguma forma ampliado sua 
visão em relação à importância dos testes, por que automatizá-los e 
por que realizá-los antecipadamente e de forma contínua. Nos 
tópicos a seguir, vamos demonstrar técnicas e ferramentas para 
criar os nossos testes. 


TDD - Test-Driven Development & ATDD - Acceptance Test- 
Driven Development 


No ATDD, para cada User Story a ser implementada, o time deve 
definir cenarios que melhor demonstrem a funcionalidade. Os 
cenarios escolhidos serao utilizados como critério de aceite da User 
Story, assim como um guia para a criação dos testes que verificará 
a sua implementação. Os testes devem ser implementados antes do 
desenvolvimento do código do sistema e, quando todos os testes 
estiverem indicando sucesso, a User Story poderá ser considerada 
finalizada. 


Como resultado da aplicação da prática do ATDD, conseguimos 
inúmeros benefícios, como: 


e Aumento de qualidade nas entregas: com os testadores 
sendo envolvidos antecipadamente desde a fase de 
planejamento, existe uma tendência de aumento na qualidade 
das entregas, pois eles têm um conhecimento e visão focados 
na qualidade. 

e Grande cobertura de testes: principalmente dos fluxos 
principais das entregas, pois testes foram selecionados e 


criados obrigatoriamente e criteriosamente para serem 
utilizados como validadores da entrega. 

e Criação de aplicação altamente testável: como os testes são 
criados antes do desenvolvimento, a funcionalidade deverá ser 
desenvolvida de forma que se encaixe nos testes. 

e Interfaces (UI e serviços) mais amigáveis: ao planejarmos e 
desenvolvermos os testes antecipadamente, estamos 
trabalhando com a visão do cliente, de quem está consumindo 
o serviço em vez da visão do desenvolvedor, que normalmente 
é técnica e não funcional. 


TDD (Test-Driven Development) ou, como costumamos falar no 
português, desenvolvimento orientado a testes, é uma técnica de 
engenharia de software que vem sendo bastante adotada e que 
consiste em criar software com base nos testes que são realizados 
antes do código da aplicação. 


O TDD foi desenvolvido por Kent Beck no final dos anos 90 como 
parte da eXtreme Programming. Em essência, você segue três 
etapas simples repetidamente: 


e Escreva um teste para a próxima unidade de código que deseja 
adicionar. 

e Escreva o código da funcionalidade até que o teste passe. 

e Refatore o código novo e o antigo para torná-lo bem 
estruturado. 


NOTA 


Para maiores detalhes, veja o link a seguir: 
https://martinfowler.com/bliki/TestDrivenDevelopment.html 





Como citado no trecho acima, para que possamos usar essa 
técnica, precisamos primeiramente pensar no método ou unidade de 
código que vamos desenvolver e criar um teste para ele. Por 


exemplo: vamos imaginar que vamos criar um método denominado 


calculadora() . 


Sabendo que vamos desenvolver esta nova unidade, vamos 
construir nosso teste para o método soma, que ainda nao está 
implementado. 


[Fact] 
public void calculadora() 


{ 


var numerol = 1; 
var numero2 = 1; 
Assert.Equal(2, soma(numero1, numero2)); 





Após implementar o método de teste, vamos criar o método soma 
sem implementação. 


private int soma(int numero1, int numero2) 


{ 


throw new NotImplementedException(); 





Ao rodar o teste, podemos perceber que ele vai falhar, entao vamos 
refatorar nosso método soma para que seja possível retornar um 
valor da soma de dois números. 


private int soma(int numero1, int numero2) 


{ 


return numerol + numero2; 





O exemplo é uma ilustração básica de como podemos implementar 
nossos testes antes da nossa aplicação em si. 


NOTA 


Para mais detalhes, consulte o livro TDD - Desenvolvimento 
Guiado Por Testes por Ken Beck. https://www.kentbeck.com/ 





8.2 Teste exploratório 


Como vimos na seção anterior, testes são essenciais para a 
verificação da qualidade, prevenção de falhas e melhor tomada de 
decisões ao longo do processo de desenvolvimento do software. 
Nesse contexto, é importante pensar em formas de explorar a 
aplicação logo na fase inicial do desenvolvimento, antes da 
execução de testes planejados, buscando possíveis bugs e pontos 
vulneráveis do sistema de forma antecipada. Para isso, são 
realizados os chamados testes exploratórios. 


Testes exploratórios são testes executados sem um planejamento 
prévio, com o objetivo de investigar comportamentos e usos da 
aplicação pelo usuário final. 


O termo teste exploratório surgiu em 1983 com Cen Kaner, 
professor de Engenharia de Software no Instituto de Tecnologia da 
Flórida e diretor do Centro de Educação e Pesquisa em Teste de 
Software da Florida Tech. Segundo Kaner, o teste exploratório é "um 
estilo de teste de software que enfatiza a liberdade pessoal e 
responsabilidade do testador individual para otimizar continuamente 
a qualidade do seu trabalho, tratando o aprendizado relacionado ao 
teste, design de teste, execução de teste e interpretação do 
resultado de teste como atividades de apoio mútuo que são 
executadas em paralelo ao longo do projeto" (KANER, 2008). 


Testes exploratorios e metodologia agil 


Os testes exploratórios possuem características comuns a 
metodologia ágil de desenvolvimento. Quando pensamos em ágil, 
estamos falando a respeito de uma natureza contínua de 
desenvolvimento, na qual os testes devem acompanhar e responder 
as mudanças de forma igualmente rápida. Dessa forma, testes 
exploratórios bem executados são aqueles que conseguem 
responder rápido a mudanças, são facilmente implementados e 
possuem abordagem fluida de desenvolvimento e execução. 


Benefícios dos testes exploratórios 


Com relação aos benefícios fornecidos pelos testes exploratórios, 
podemos destacar: 


e Detecção antecipada de erros: sendo realizada logo no início 
do desenvolvimento do software, é possível detectar possíveis 
bugs mais rapidamente, diminuindo a necessidade de 
correções tardias. 

e Agilidade nos ciclos de teste: não há planejamento para a 
execução do teste exploratório (design e execução ocorrem 
simultaneamente), logo pode ser implementado de forma 
rápida, provendo maior velocidade aos ciclos de teste. 

e Feedbaks rápidos: os feedbacks são rapidamente obtidos, o 
que possibilita que a equipe efetue as mudanças necessárias 
logo no início e, com isso, foque no planejamento e 
implementação dos demais tipos de teste. 


O teste exploratório pode ser compreendido como um tipo de teste 
complementar aos demais, na medida em que faz uso do 
julgamento e criatividade do testador na busca de possíveis erros e 
defeitos do software. Além disso, um bom teste exploratório consiste 
na experiência do testador e no conhecimento que vai sendo 
adquirido ao longo da execução do teste. 


No caso da nossa aplicação eShopOnWeb, realizaremos testes 
exploratorios para investigar se tudo esta funcionando corretamente, 
verificando situações que possam conter defeitos, ocasionar erros e 
como reportá-los. 


Execução de testes exploratórios com Test & Feedback 


Para apoio à execução de testes exploratórios, pode ser utilizada a 
extensão gratuita Test & Feedback, da Microsoft, disponível 
atualmente para os navegadores Edge, Chrome e Firefox 
(MICROSOFT DOCS; Install the Test & Feedback extension, 2019). 


NOTA 


Nos exemplos aqui apresentados, utilizaremos o navegador 
Chrome. 





Com essa ferramenta é possível fazer capturas de tela, anotações e 
gravações dos problemas encontrados pelos testes exploratórios, 
contribuindo para um melhor planejamento e controle das ações a 
serem tomadas após a execução desses testes. 


A extensão pode ser encontrada no Visual Studio Marketplace, em 
Azure DevOps -> Azure Test Plans -> Test & Feedback. 


bi VisualStudio | Marketplace 
Azure DevOps > Azure Test Plans > Test & Feedback 


Test & Feedback 
Microsoft | d 130,682 clicks | ddr kJ (140) | Free 


Now everyone on the team can own quality. Capture findings, create issues, and collaborate with 
the team, directly from the browser. 


Install 


Figura 8.5: Extensão Test & Feedback 


NOTA 


É possível utilizar a extensão Test & Feedback nos modos 
Connected e Standalone. 


Nos exemplos aqui apresentados, será utilizado o modo 
Standalone, que não requer conexão com Azure DevOps 
Services ou Azure DevOps Server. Para mais informações, 
consulte: https://marketplace.visualstudio.com/ 





Os passos a seguir mostram como instalar a extensão no navegador 
Chrome. 


Instalação da extensão Test & Feedback 


O primeiro passo para instalar a extensão consiste em selecionar a 
opção Usar no Chrome (ou Add to Chrome): 


Página inicial > Extensões > Test & Feedback 


lo Test & Feedback 


Oferecido por: Microsoft Corporation 


KK dk dr 162 | Produtividade | & 100.000+ usuários 


Figura 8.6: Extensão Test & Feedback para Google Chrome. 


Em seguida, selecione Add extension: 
ko Add "Test & Feedback"? 


It can: 
Read and change all your data on the websites you visit 
Read data you copy and paste 


Capture content of your screen 





Figura 8.7: Pergunta de confirmação para instalação no Chrome. 


A extensão é então instalada, aparecendo a seguinte mensagem: 


yh Test & Feedback has been added to 
O Chrome 


Use this extension by clicking on this icon or by 


pressing Ctrl+Shift+Y. 


Manage shortcuts 


Figura 8.8: Confirmação da instalação no Chrome. 


Teste exploratório no eShopOnWeb 


O primeiro passo para realizar o teste exploratório com o apoio da 
ferramenta Test & Feedback é acessar a aplicação web que se 
deseja testar no navegador em que está instalada a extensão. No 
modo Standalone, inicie a gravação, clicando no ícone Play. 


a x |b 
[>| so 


į Connection settings — 


| © Connected Standalone 


Make notes, take screenshots, file bugs, and share your findings as a 
report. Open to everyone. No connection to Azure DevOps Services or 
Team Foundation Server required. Learn more 


Don't have a Azure DevOps organization? Sign up for free. 


Start the session to continue exploring your application. 





Figura 8.9: Modo Standalone da extensão Test & Feedback. 


No decorrer da execução do teste exploratório, havendo algum bug 
ou problema que seja necessário investigar, é possível fazer uma 
captura da tela clicando no ícone com símbolo de câmera. 


Capture screen 





Figura 8.10: Captura de tela com Test & Feedback. 


Agora vamos acessar nossa aplicação eShopOnWeb. Ao realizar o 
teste exploratório, navegamos pela aplicação simulando interações 
reais que um usuário teria - interações essas que são pensadas no 
momento em que o teste está sendo executado, sem nenhum 


planejamento prévio. Ao acessar a nossa aplicação, temos a 
seguinte visualização: 


& localhost:44315 a x ht 


[Catia won 9 


ALL 
ON SALE 


THIS WEEKEND 





Previous Showing 10 of 12 products - Page 1 - 2 Next 





a j TAN ZEZ EEE 
1 RR EEE Eate EE 
(aD Vite t 255 ~ é As eda 
[ADD TO BASKET ] [ADD TO BASKET ] [ ADD TO BASKET ] 


ROSLYN RED SHEET -NET FOUNDATION SWEATSHIRT PRISM WHITE T-SHIRT 
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Figura 8.11: Pagina inicial da aplicação eShopOnWeb. 


Ao executar a extensão Test & Feedback, no lado superior direito da 
tela, é possível ver a barra de opções da ferramenta e a mensagem 
de que a sessão de teste está acontecendo, como pode ser visto na 
imagem a seguir. 





ssion running. Menus are activated. Select to stop. 


i a, E 


Session running. Menus are activated. Select to stop. 


Figura 8.12: Extensão Test & Feedback em execução. 
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Os seguintes passos exemplificam como podemos executar o teste 
exploratório na aplicação eShopOnWeb. Podemos começar 
realizando o login de forma bem-sucedida, em seguida navegamos 
pela aplicação, tanto pela primeira página quanto pela segunda, 


sem problemas. Utilizamos os menus de pesquisa e filtramos os 
produtos de interesse. Selecionamos um produto e o adicionamos 
ao carrinho. Tudo funciona como esperado até aqui. 


Seguindo com o teste exploratório, na tela de carrinho (ou Basket), 
percebemos que não há um botão para remover o item. Há apenas 
um botão Update, que precisa ser selecionado se quisermos alterar 
a quantidade de itens do carrinho. Descobrimos que, ao tentar 
alterar o número de itens no campo Quantity e em seguida clicar 
diretamente no botão Checkout, somos redirecionados para a 
página de checkout sem realmente ter alterado a quantidade de 
itens. 


® Test & Feedback | chrome-extension://gnldpbnocfnlkkicnaplmkaphfdniplb/AnnotationTool/AnnotationToolHost.html Clim D 


je Full 
uliscreen 
KEN 


QUANTITY 


$12.00 


TOTAL 
$12.00 


[ UPDATE ] [ CHECKOUT ] 





Figura 8.13: Captura de tela durante o teste exploratório. 


Para evidenciar esse problema, podemos capturar as telas sobre 
esse comportamento da aplicação, bem como adicionar anotações 
sobre o problema. 


o we} 2,4 8 © 


Note * x 


Não ha qualquer botão para remover o item do carrinho e não é 
possível alterar de fato a quantidade de itens clicando somente em 
Checkout, é necessário clicar primeiro em Update, porém não há 
nenhum indicativo sobre isso na tela] 


Save 





Figura 8.14: Anotação durante o teste exploratório. 


Por último, podemos criar um bug e vincular as capturas de tela 
realizadas bem como as anotações. 


DO BE 0 e O 





New bug x 
Dificuldade para atualizar quantidade de itens no carri | O Similar 
Include: Image action log Page load data 


- EZK 
Source: https://localhost:44315/Basket/Checkout 


Não há qualquer botão para remover o item do carrinho e não é possível altera 








Image action log and page load data collection options are available in Connected 
mode only 


Save 





Figura 8.15: Criação de bug 


Durante a execução do teste exploratório, também é possível 
visualizar a linha do tempo da sessão de teste, os passos realizados 
e o tempo em que foram executados na opção View session 
timeline. 





iew session timeline 


O la, E AE) & O 


Session timeline (4) — 


(11) Now O 19:37 
| Bug 1 O 19:36 


Dificuldade para atualizar quantidade de itens no 
carrinho 


Note-1 @ 19:35 


Não há qualquer botão para remover o item do carrinho e não é 
possível alterar de fato a quantidade de itens clicando somente em 
Checkout, é necessári... 


Screenshot-1.png O 19:33 





Figura 8.16: Linha do tempo do teste exploratório. 


Ao final do teste exploratório, é gerado um relatório Session 
Report.html, contendo o resumo das ações realizadas durante toda 
a sessão de teste, incluindo os bugs registrados, capturas de tela e 
anotações. 


. r y 10/26/2020 07:30 PM 

Session Report Exported On: 10/26/2020 07:37 PM 
Tact 2 Feadbáci Bu Filed 1 

ko i x i 1e Z Brasilia Standard Time 


g Test & Feedback extension Azure DevOps Services 
Test & Feedback Marketplace page 


Summary of bugs filed 


Bug 1 Dificuldade para atualizar quantidade de itens no carrinho 


Bug 1 


Dificuldade para atualizar quantidade de itens no carrinho 





Figura 8.17: Relatório da sessão de teste gerado automaticamente pela extensão. 


8.3 Teste de unidade 


Para que possamos entender melhor sobre o teste de unidade, 
vamos primeiramente entender alguns conceitos: Uma unidade é a 
menor parte testável de um programa de software. Podemos 
chamar a validação dessa menor parte (unidade) do programa de 
software de teste de unidade ou unit test. 


Os testes de unidade vêm cada vez mais se popularizando pelo 
simples fato de que, hoje em dia, os times de desenvolvimento vêm 
adotando cada vez mais os conceitos de TDD (Test-Driven 
Development) e Shift Left Testing, como mencionado na introdução 
deste capítulo. 


Quando usar? 


Algumas dúvidas são muito comuns durante o ciclo de 
desenvolvimento de software, tais como: 


e Quando devo escrever os meus testes? 
e Que tipo de testes eu coloco no meu projeto? 
e Não é perda de tempo escrever testes de unidade? 


Respondendo a essas dúvidas, é importante saber que quanto mais 
testes você conseguir automatizar no início do seu projeto, menor a 
quantidade de erros, evitando desperdícios ao longo do 
desenvolvimento e melhorando a manutenibilidade do software. 
Evita-se também aparição de bugs no projeto causados por testes 
tardios e mantém uma dívida técnica baixa (bem como 
exemplificado pela pirâmide adaptada por Martin Fowler mostrada 
na seção inicial deste capítulo). 


O teste de unidade 


Um teste de unidade testa o menor pedaço de software testável 
(uma unidade) isoladamente. Portanto, se um único método é 
considerado uma unidade, um teste de unidade real executaria 
apenas esse método e nada mais. Mesmo chamar outro método 
privado ou algo simples como object.Tostring() nessa definição 
restrita, faria com que um teste não fosse mais um teste de unidade. 
Nesse caso, um teste com partes integradas seria chamado de teste 
de integração. 


Testes de Unidade | Testes de Integração 


Unidade de código 


Outras Unidades; 
API's; 
Partes de terceiros. 





Figura 8.18: Arquitetura do teste de unidade. 


NOTA 


Este tópico é destinado a explicar e exemplificar os testes de 


unidade, não sendo abordados em detalhes conceitos e 
exemplos de testes de integração. 





Uma boa prática que podemos descrever ao falar sobre os testes de 
unidade são os testes de: 


Regressão, nos quais podemos utilizar os testes de unidade para 
validar se tudo que estava funcionando não foi quebrado com um 
novo desenvolvimento. Será executada uma suíte de testes 
preexistente para garantir que o sistema ainda atenda aos requisitos 
de qualidade. 


Fumaga, que sao testes pequenos e leves, que visam confirmar se 
uma nova mudança funciona e nao desestabiliza o sistema. Sao 
executados após a mudança, procurando fumaça no sistema; caso 
não encontre a fumaça, então o teste passa. 


Alguns questionamentos são feitos pelos desenvolvedores ao terem 
que escrever os testes de unidade: Qual o benefício de escrevé-los? 
Não é muito esforço? Estou desperdiçando tempo do meu ciclo? 


No próximo tópico, vamos ver um pouco dos benefícios de se 
automatizar os testes com testes de unidade e testar o software no 
início do seu desenvolvimento. 


Benefícios dos testes de unidade 


Alguns dos benefícios podem ser citados quando executamos os 
testes de unidade: 


e Encontra os defeitos antecipadamente: uma das principais 
vantagens e benefícios de se automatizar os testes de unidade 
e executá-los é poder ter a garantia de que vamos encontrar os 
defeitos bem antes de o software ir para a produção, podendo 
assim reduzir o custo de correção de bugs durante o 
desenvolvimento. 
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Figura 8.19: Custo de correção de bugs. 


e Evita o retorno de defeitos (regressão): como já mencionado 
acima, uma boa suíte de testes unitários também ajuda a 
prevenir a regressão de problemas e defeitos. É uma boa 
prática criar um teste toda vez que um novo bug for encontrado. 
Assim, caso alguma alteração futura faça com que o bug 
retorne, o teste vai indicar. 


e Provê documentação viva (código-fonte): entenda que, para 
cada classe de produção no seu sistema, existem diversos 
métodos de teste que exercitam e exemplificam todos os seus 
usos possíveis. Uma boa suíte de testes poderia ajudar um 
recém-chegado ao time adquirir familiaridade com a base de 
código em pouco tempo, ou seja, documentação viva, 
executável, sempre atualizada e que nunca mente. 


e Reduz o esforço de testes manuais: testes manuais hoje em 
dia demandam muito esforço humano para serem escritos 
baseados nos critérios de aceite e executados durante o ciclo 
de desenvolvimento. Portanto, quanto mais automatizado seus 
testes forem, menos esforço com testes manuais terão que ser 
utilizados para garantir a qualidade do software. 


Vamos imaginar o seguinte cenário: antes de cada release, a sua 
equipe faz um teste completo na aplicação, com quatro testadores, 
trabalhando oito horas por dia durante duas semanas. Basta fazer 
uma simples multiplicação e você verá que testes manuais custam 
caro. Eles custam caro duas vezes. Primeiro, há o custo dos testes 
em si como podemos ver na forma exemplificada na nota abaixo: 


NOTA 


Custo dos Testes = valor da hora x nº de testadores x horas 
gastas em testes. 





Segundo, quando profissionais precisam desempenhar testes 
manuais que poderiam automatizar, deixam de fazer outras 


atividades que poderiam trazer mais ganhos e/ou impactos para a 
empresa. 


Alguns outros beneficios dos testes de unidade incluem: incentivo a 
refatoração, incentivo à evolução da arquitetura do sistema, 
simplificação e agilidade na entrega do produto aos usuários. 


Métricas 


Quando escrevemos os testes de unidade para um código-fonte de 
um sistema grande e complexo, precisamos saber como medir a 
quantidade de código que está sendo testado. Isso ajuda a garantir 
um teste de regressão mais confiável. Podemos ter essa informação 
com uma métrica chamada de Code Coverage ou Cobertura de 
Código. 


Cobertura de Código 


A cobertura de código é uma métrica utilizada para medir a 
quantidade de código que foi testada por uma suite de testes escrita 
para validação do software. 


A cobertura de código funciona da seguinte maneira: ela analisa 
todos os assemblies gerados, que são carregados no momento da 
execução dos testes de unidade, e o resultado é o quanto do seu 
código-fonte está coberto por testes, garantindo uma maior 
qualidade da aplicação. 


Para isso é necessário entender como implementar os testes da 
melhor forma possível usando os padrões e boas práticas. No 
próximo tópico, vamos abordar as boas práticas para a 
implementação desses testes de unidade, bem como arquitetura, 
uso de framework, padrões, entre outros. 


Boas práticas para testes de unidade 


Framework 


Programas de testes são projetados para executar o código que 
está sob teste e verificar os resultados automaticamente. Com os 
benefícios das linguagens orientadas a objetos, essa abordagem se 
tornou mais amplamente conhecida. O teste de unidade foi 
consolidado e frameworks foram criados para facilitar o 
desenvolvimento e execução desse tipo de teste. 


Existe um grande número de estruturas de teste de unidade para 
todos os tipos de linguagens de programação e a grande maioria 
delas segue o mesmo padrão de design. No núcleo dessas 
estruturas, na maioria dos casos, está uma biblioteca de teste de 
unidade, que oferece pontos de extensão específicos da plataforma, 
bem como: 


e Blocos de código como sendo um teste de unidade. 
e Suposições sobre o comportamento do código em teste. 
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Figura 8.20: Framework unit test. 
Padroes 


Existem alguns padrões que podemos adotar para facilitar o 
desenvolvimento, entendimento e manutenibilidade do código-fonte 


de teste. Neste tópico, vamos citar alguns pontos de atenção e as 
boas práticas que devemos implementar quando estamos 
desenvolvendo nossos testes, são elas: 


e Nomenclatura dos testes; 
e Organização AAA no teste; 
e Evitar lógicas em testes. 


Nomenclatura dos testes expressa e ajuda a entender a intenção 
deles. A ideia de um teste de unidade aqui não é somente validar o 
código-fonte. Um teste de unidade também pode fornecer uma boa 
documentação para sua aplicação e possibilitar uma rápida 
identificação dos cenários que não atendem às expectativas da 
aplicação caso o teste falhe. 


[Fact] 
public void Add SingleNumber ReturnsSameNumber () 
{ 


var stringCalculator = new StringCalculator(); 
var actual = stringCalculator.Add("0"); 
Assert.Equal(@, actual); 





Organização AAA no teste é normalmente utilizada quando vamos 
construir um teste de unidade para organizar o nosso código em três 
principais ações, que são: 


e Arrange: organiza, cria ou configura os objetos do teste; 
e Act: é a ação efetuada em um objeto do teste; 
e Assert: valida o retorno do teste baseado na expectativa. 


Isso ajuda a dar uma melhor leitura para o teste, deixando claro 
como o seu código-fonte está sendo chamado e validado. O objetivo 
principal dessa boa prática é deixar o teste o mais legível possível. 


[Fact ] 
public void Add EmptyString ReturnsZero() 


{ 


// Arrange 
var stringCalculator = new StringCalculator(); 


// Act 
var actual = stringCalculator.Add(""); 


// Assert 
Assert.Equal(@, actual); 





Evitar logica em testes, tais como if, while e for, pois isso reduz a 
chance de um bug ser introduzido dentro dos testes. Ou seja, um 
teste de unidade deve se concentrar em testar a aplicagao e no 
resultado da validação e não em implementação de lógica de 
programação. O teste de unidade é o último lugar em que se pode 
desejar encontar um bug, caso contrário eles deixam de ser 
confiáveis, sendo assim não trazem nenhum valor. A ideia principal 
é que, quando um teste falha, supõe-se que há um problema no seu 
código-fonte e não no próprio teste. 


Segue um exemplo de como não se deve programar um teste e um 
outro exemplo do cenário ideal. 


Cenário de teste com lógica de programação. 


[Fact ] 
public void Add MultipleNumbers_ReturnsCorrectResults() 


{ 


stringCalculator = new StringCalculator(); 
expected = @; 
testCases = new[ ] 


"0,0,0", 

"0,1,2", 

"4,2,3" 
}; 


foreach (var test in testCases) 

{ 
Assert.Equal(expected, stringCalculator.Add(test)); 
expected += 3; 





Cenário de teste sem lógica de programação. 


[Theory] 

[InlineData("0,0,0", 0)] 

[InlineData("0,1,2", 3)] 

[InlineData("1,2,3", 6)] 

public void Add MultipleNumbers ReturnsSumOfNumbers ( 
string input, 
int expected) 


var stringCalculator = new StringCalculator(); 


var actual = stringCalculator.Add(input); 


Assert.Equal(expected, actual); 





Mock objects de testes 


Para entender melhor o que é um mock object, primeiramente 
vamos entender o seguinte cenario. Sabemos que um teste de 
unidade é o teste executado na menor parte de uma aplicação. Às 
vezes precisamos passar algumas informações (inputs) bem como 
acessar resultados de APIs ou informações em um banco de dados 
para que nossos testes sejam feitos de forma eficiente (ou até 
mesmo criar uma bateria de testes). Porém, se estamos testando 
apenas aquela unidade de código, ela tem que ser testada de forma 
isolada. Não podemos depender de nenhuma outra parte do código. 
É neste momento que contamos com a ajuda dos objetos mock. 


Mock objects, ou simplesmente mocks são objetos criados com 
o intuito de simular objetos reais e existentes na aplicação com 
informações necessárias para testar a unidade. 


Nos testes de unidade, o uso dessa prática é muito comum para 
simular os comportamentos de objetos reais, e existem algumas 
técnicas e tecnologias que são utilizadas para isso. O que podemos 
citar de mais atual sendo utilizado pelas pessoas desenvolvedoras é 
o MOQ Framework. Boas práticas e exemplos do MOQ Framework 
serão mostrados nos exemplos de testes de unidade para o 
eShopOnWeb. 


As técnicas e boas práticas citadas anteriormente serão utilizadas 
no exemplo da nossa aplicação eShopOnWeb. 


NOTA 


Para melhores práticas, consulte a documentação abaixo. 


https://docs.microsoft.com/dotnet/core/testing/unit-testing-best- 
practices 





Teste de unidade no Visual Studio & Test Explorer 


O Visual Studio fornece uma ótima ferramenta para que as pessoas 
desenvolvedoras executem os seus testes, que é o Test Explorer. 
Essa ferramenta é muito útil para organizar, categorizar e criar 
playlists de testes, além de possibilitar a execução de projetos de 
testes criados no próprio Visual Studio ou projetos de testes de 
terceiros. Também pode-se analisar a cobertura de código e efetuar 
debug nos testes de unidade. 


Quando os projetos de testes são compilados pelo Visual Studio, os 
testes são exibidos no Test Explorer. 


Duration Error Message 
a ES UserSentimentânalysis.Tests (17) 83 ms 
4 ÉS UserSentimentAnalysis.Tests (17) 83 ms 
4 O EmojiTests (5) 6 ms 
O EmojiClothingTest 5 ms 
© EmojiExtraSpecialCharatersTest <1ms 
O EmojiFaceSearchTest 1ms 


O EmojiHeartsTest <1ms 
O TearsOfloyTest «ms 

b db HomeControllerTests (6) 

4 D TwitterDataModelTests (6) 77 ms 
E ActiveCognitiveServiceTest T4ims Assert.AreEqual failed, Expected... 
© Average TweetTest 3ms Test method UsersentimentAna... 
OO GetTweetSentimentTest «ms Assert.AreEqual failed. Expected... 
EM HistoricalTweetTest «ms Assert.ArcEqual failed, Expected... 
© MultipleAverageTweetTest <1ms 
ED ParseTweetTest «ms Assert.AreEqual failed. Expected... 





Group Summary 
TwitterDataModelTests 
Tests in group: 6 
(©) Total Duration: 77 ms 
Outcomes 
O à Passed 
@ 5 Failed 


Figura 8.21: Visual Studio Test Explorer. 


A maior parte das ações, como encontrar, organizar e executar 
testes podem ser feitas usando a barra de ferramentas do Test 
Explorer como mostrado na figura a seguir: 


Filter by passed, failed, not run 


Repeat last test run Start Live Unit Testing Test settings 





al tt ¥ Search Test Explorer p E 


d A 





B 17/06/05 |O6 





Number of total tests Choose a category for grouping tests 





Create or run a test playlist Search/filter tests 








Figura 8.22: Visual Studio Test Runner. 


Conforme as ações de execução, gravação e reexecução dos testes 
são efetuadas, o Test Explorer exibe um agrupamento com os 
resultados de testes falhos, testes executados com sucesso, 
ignorados e não executados. Na parte inferior da ferramenta, pode- 
se visualizar os detalhes e resumo da execução dos testes. 


»r-Coláriorios B- ET- 
Test « Duration af Test Detail Summary 
4 © UserSentimentAnalysis.Tests (17) sec @ AverageTweetTest 
4 O Emojtests (5) É E Source; IwitterDataModelTests.cs line: 56 
O EmojiClothingTest s © Duration: 3 ms 
O EmojiExtraSpecialCharatersTest 
© Emoji sarchTes ms Menage: 
O EmojiHeartsTest ZEZ Test method UserSentimentAnalysis. Tests. TwitterDataModellests.AverageTweetTest threw exception: 
System, ArgumentOutOfRangeException: Index was out of range. Must be non-negative and less than the size of the collection. 
O TearsOt/oyTest D 
Parameter name: index 
Stack Trace: 
at List 1.get Item(Int32 index) 
ri Twi 





Figura 8.23: Visual Studio Test Results. 


Para mais detalhes sobre o uso do Test Explorer no Visual 


Studio, consulte o link a seguir: 
https://docs.microsoft.com/visualstudio/test/run-unit-tests-with- 
test-explorer 





Testes de unidade no eShopOnWeb 


Neste tópico, vamos iniciar a implementação de testes de unidade 
para a aplicação eShopOnWeb, a qual, neste momento, está no seu 
modo legado sem desacoplamento e ainda não modernizada. 


Como exemplo de testes de unidade na aplicação, vamos escolher 
algumas unidades de código. 


Teste de adição de um item na cesta: 


[Fact ] 
public async Task Add An Item To BasketAsync() 


{ 


//Arrange 
var mockRepository = new Mock<IAsyncRepository<Basket>>(); 
var mockLoger = new Mock<IAppLogger<BasketService>>(); 


var basketid = 1; 
var catalogitemid = 1; 
var buyerid = "1"; 


var basket = new Basket(buyerid); 


mockRepository.Setup(x => x.FirstOrDefaultAsync( 
It. IsAny<BasketWithItemsSpecification>())) 
.Returns(Task.FromResult(basket) ) ; 


var basketService = new BasketService( 
mockRepository.Object, 
mockLoger.Object) ; 


//Act 

await basketService.AddItemToBasket ( 
basketid, 
catalogitemid, 
22); 


//Assert 
Assert.Equal(1, basket.Items.Count) ; 
Assert.Equal(catalogitemid, basket.Items.First().CatalogItemId) ; 





Teste de deleção da cesta: 


[Fact] 

public async Task Delete Basket() 

{ 
//Arrange 
var mockRepository = new Mock<IAsyncRepository<Basket>>(); 
var mockLoger = new Mock<IAppLogger<BasketService>>(); 


var basketid = 1; 
var catalogitemid = 1; 
var buyerid = "1"; 


var basket = new Basket(buyerid) ; 
basket .AddItem(catalogitemid, 22); 


mockRepository.Setup( 
x => x.GetByIdAsync(basketid) ) 
. Returns (Task.FromResult (basket) ); 


mockRepository.Setup( 
x => x.DeleteAsync(basket) ) 
.Callback(() => { basket = null; 3); 


var basketService = new BasketService( 
mockRepository.Object, 
mockLoger.Object) ; 


//Act 
await basketService.DeleteBasketAsync(basketid) ; 


//Assert 
Assert.Null(basket) ; 





Teste de mudanga de quantidade de um item na cesta: 


[Fact] 
public async void Add An Item To Basket And Set Quantities() 
{ 
//Arrange 
var mockRepository = new Mock<IAsyncRepository<Basket>>(); 
var mockLoger = new Mock<IAppLogger<BasketService>>(); 


basketid = 1; 
catalogitemid = 1; 


buyerid = "1"; 


var basket = new Basket(buyerid); 
basket.AddItem(catalogitemid, 22); 


var quantities = new Dictionary<string, int>() { { "0", 2 } }3 


mockRepository.Setup( 


x => x.FirstOrDefaultAsync( 
It.IsAny<BasketWithItemsSpecification>())) 
. Returns (Task.FromResult (basket)); 


var basketService = new BasketService( 
mockRepository.Object, 
mockLoger.Object) ; 


//Act 
await basketService.SetQuantities(basketid, quantities) ; 


//Assert 

Assert.Equal(1, basket.Items.Count) ; 

Assert.Equal(2, basket.Items.First().Quantity) ; 

Assert.Equal(catalogitemid, 
basket.Items.First().CatalogItemId) ; 

Assert.Equal(22, basket. Items.First().UnitPrice) ; 





8.4 Resumo 


Neste capitulo, abordamos os conceitos de testes e seus beneficios, 
bem como alguns exemplos de implementação de tipos de testes de 
unidade: 


e Mostramos a importância dos testes nas aplicações e o 
momento recomendado para desenvolvê-los. 

e Abordamos práticas e ferramentas utilizadas em testes 
exploratórios. 

e Vimos as boas práticas para o desenvolvimento de testes de 
unidade e seus benefícios. 


CAPITULO 9 
Automação em ambientes de testes 


Escrito por Augusto Araujo, Beatriz Matsui, Eric Shimokawa e 
Fernando Henrique Inocêncio Borba Ferreira. 


CENÁRIO 


Continuando com os conceitos de testes, um ponto muito 
importante para entender é que, para que os testes sejam 
efetivamente validados, é necessário que seus ambientes sejam 
configurados de forma isolada, garantindo um teste mais 
assertivo e possibilitando sua automação. 


Neste capítulo, serão abordados os ambientes onde 
recomendamos a execução dos testes automatizados, e 
detalharemos qual tipo de teste podemos realizar neles, por 
exemplo, testes de interface. 


Por fim, será feita a reconfiguração do Cl e CD acrescentando 
os testes automatizados criados no capítulo anterior e também 
neste. 





9.1 Teste de Interface 


Testes de interface do usuário (IU) são testes que visam simular a 
utilização de uma aplicação pelo usuário final - seja uma aplicação 
web, desktop ou mobile. Baseiam-se em requisitos funcionais e 
almejam descobrir se esses requisitos foram atendidos e se a 
aplicação está funcionando corretamente. 


Geralmente sao testadas funcionalidades criticas para o sistema, 
que podem ir desde a escolha de um produto (seleção de um item 
na tela), até o processo de colocar esse item no carrinho e, por fim, 
efetuar a compra (considerando uma aplicação e-commerce como a 
eShopOnWeb). 


Teste manual vs. teste automatizado 


Os testes de interface podem ser feitos de forma manual ou 
automatizada. Na forma manual, uma pessoa é responsável por 
efetuar um conjunto de operações na tela com o objetivo de verificar 
se serão obtidos os resultados esperados. Já na forma 
automatizada, são desenvolvidos programas de teste que vão 
efetuar os passos necessários correspondentes à utilização da 
aplicação pelo usuário de acordo com o que ele vê na tela. 


No caso de aplicações como a eShopOnWeb, o mais recomendado 
é a execução de testes automatizados, que proveem maior 
eficiência e confiabilidade em comparação aos dispendiosos e 
menos eficazes testes manuais. 


Benefícios dos testes automatizados 


Os testes automatizados de interface possuem alguns benefícios, 
tais como: 


e Redução de erros: com a automatização, testes se tornam 
menos propensos a erros se comparados aos testes manuais. 

e Maior produtividade e eficiência do tempo: com economia de 
tempo na execução, fornecem maior agilidade ao ciclo de 
desenvolvimento como um todo. 

e Feedbacks rápidos: como permitem detectar problemas de 
forma antecipada, a validação do desenvolvimento em suas 
diferentes fases é mais veloz e eficiente. 

e Reusabilidade: os códigos de teste podem ser reutilizados em 
outros projetos ou casos de teste, fornecendo maior praticidade 
e redução nos custos e tempo de desenvolvimento. 


Existem diversas ferramentas que auxiliam na criação e 
desenvolvimento de testes automatizados de interface. Para 
aplicações web, como no caso da eShopOnWeb, utilizaremos o 
Selenium. 


9.2 Testes Automatizados de Interface com 
Selenium 


Selenium é um conjunto de ferramentas para automatização de 
testes em aplicações web. É bastante utilizado pois, além de ser 
open-source, é multiplataforma, possibilitando a codificação em 
diferentes linguagens, tais como C#, Java, Python e Ruby. 


Os seguintes elementos compõem o framework de testes do 
Selenium: 


e Selenium WebDriver: API (Application Programming Interface) 
que permite o controle do navegador e execução de testes 
automatizados simulando a interação do usuário com a página 
web. 


e Selenium IDE (Integrated Development Environment): 
ferramenta utilizada para desenvolver casos de teste de forma 
automática por meio da interação do usuário com a página. 
Consiste em uma extensão para navegadores (atualmente 
suportados: Chrome, Firefox, Edge, IE, Opera e Safari), que 
registra as ações executadas pelo usuário gravando-as e 
gerando scripts de teste. 


e Selenium Grid: hub que possibilita a execução de testes com 
WebDriver em máquinas remotas (físicas ou virtuais), em 
diferentes plataformas, de forma simultânea. O controle de 
acionamento da execução dos testes fica na extremidade local, 


enquanto na extremidade remota sao executados os testes 
automaticamente. 


NOTA 


Neste livro nao sera abordada a utilizagao de Selenium IDE, 


tampouco de Selenium Grid, uma vez que faremos uso somente 
do Selenium WebDriver no desenvolvimento dos testes. 


Para mais informações, consulte https://www.selenium.dev 





Selenium WebDriver 


O WebDriver do Selenium possibilita a utilização de diferentes 
navegadores para a execução dos testes automatizados. Ele 
consiste em uma interface de programação concisa que suporta 
codificação em linguagens, como Java, Python, C#, Ruby e 
JavaScript (SELENIUM; WebDriver, 2020). Nos exemplos aqui 
apresentados, utilizaremos a linguagem de programação CÊ. 


Antes de partirmos para os exemplos e para a codificação dos 
testes é importante entendermos os diferentes componentes que 
são utilizados pelo WebDriver. 


Componentes 


O WebDriver se comunica com o navegador web por meio de um 
driver desse navegador. A figura a seguir ilustra essa comunicação 
entre WebDriver, driver e navegador (browser). 


Browser 


WebDriver 


Bindings + 
support classes 


E 
O 
ebei 
” 
> 
dA 
ebei 
” 
O 
a 


Driver 
ChromeDriver, eg 





Figura 9.1: WebDriver - Understanding the components. Fonte: SELENIUM; WebDriver, 
2020. 


NOTA 


O exemplo ilustrado acima representa uma comunicação direta 
entre WebDriver e navegador, na qual ambos estão sendo 


executados no mesmo sistema. Também é possível efetuar essa 
comunicação de forma remota, a qual não abordaremos neste 
livro. Para mais informações sobre comunicação remota entre 
WebDriver e navegador, consulte https://www.selenium.dev. 





O WebDriver tem como função se comunicar com o navegador, não 
tendo conhecimento algum sobre os testes. Para que isso aconteça, 
é necessária a utilização de frameworks de teste relacionados às 


suas respectivas linguagens e estruturas, como NUnit ou xUnit para 
linguagens .NET, JUnit para Java etc. 


Exemplos de códigos 


Seguem alguns exemplos de códigos com WebDriver: 


//Abrir o navegador e acessar URL 
driver .Navigate().GoToUrl("https://www.microsoft.com/"); 


//Maximizar tela 
driver.Manage().Window.Maximize(); 


//Procurar e selecionar elemento (por ID) 
driver.FindElement (By. Id("123")).Click(); 


//Procurar e selecionar elemento (por XPath): 
driver.FindElement (By.XPath("/xpath-exemplo"3).Click(); 


//Fechar aba ou janela do navegador 
driver.Close(); 


//Encerrar sessão do navegador 
driver.Quit(); 





Observação: o comando quit() vai encerrar todo o processo do 
navegador, fechar quaisquer abas e janelas abertas e encerrar 
qualquer processo do driver que esteja sendo executado em 
segundo plano. 


Padrão Page Object 


Page Object é um padrão de projeto comumente utilizado em testes 
automatizados de interface que ajuda a reduzir duplicidade de 
código e a aprimorar a manutenibilidade dos testes (SELENIUM; 
Page object models, 2020). 


Esse padrao cria objetos de pagina (page objects), que representam 
cada pagina web acessada pelo teste, encapsulando os métodos e 
atributos em classes, que servem como interfaces para as paginas. 
Os métodos dessas classes sao então utilizados quando os testes 
precisam interagir com os elementos das paginas representando as 
ações a serem realizadas nelas. 


Alguns dos benefícios de se utilizar o padrão Page Object incluem: 


e Separação entre os códigos de teste e os da interface do 
usuário: há uma separação clara de responsabilidades entre o 
que concerne aos códigos de teste e aos de interface - sendo 
estes os que farão uso da API do WebDriver. Os códigos de 
teste, por sua vez, serão responsáveis por chamar os métodos 
que interagem com a interface, além de verificar os resultados 
(asserts). 


e Abstração e encapsulamento: as páginas da aplicação sao 
abstraídas em classes que contêm os atributos e métodos 
utilizados pelo WebDriver para acessa-las sem misturá-los com 
os códigos de teste. Dessa forma, o acesso aos elementos das 
páginas é encapsulado pelos page objects, fornecendo para os 
códigos de teste apenas os métodos que serão chamados 
quando for preciso efetuar ações sobre as páginas que serão 
testadas. 


Segue um exemplo de implementação do caso de teste Login para 
a aplicação eShopOnWeb sem a utilização de page objects. Neste 
caso é criado apenas um método que será responsável por todo o 
acesso aos elementos da página e pelos testes, sem nenhuma 
abstração ou separação de responsabilidades. Havendo qualquer 
mudança na interface, também será necessário modificar os códigos 
de teste. 





using System; 

using Xunit; 

using OpenQA.Selenium; 

using OpenQA.Selenium.Chrome; 


namespace UITests 


{ 


public class Login 


{ 


IWebDriver driver = new ChromeDriver( 
Environment.CurrentDirectory) ; 


[Fact ] 
public void testaLogin() 


{ 
driver.Navigate().GoToUrl("https://localhost:44315/"); 


IWebElement meuLogin, username, password, btn_login; 
meuLogin = driver.FindElement ( 


By.XPath("/html/body/div/header/div/article/section[2]/div/section/div 
/a")); 
meuLogin.Click(); 


username = driver.FindElement( 
By.XPath("//*[@id='Input_Email']")); 
password = driver.FindElement( 
By.XPath("//*[@id='Input_Password']")); 
btn_login = driver.FindElement( 


By.XPath("/html/body/div/div/div/div/section/form/div[5]/button")); 
username. SendKeys ( "demouser@microsoft.com"); 
password .SendKeys("Pass@word1"); 


btn_login.Click(); 


driver.Quit(); 


Já com uso de page objects, temos a divisão entre o acesso aos 
elementos da interface e os códigos de teste. A seguir, pode-se 
visualizar o código de um page object criado para abstrair elementos 
de interface da página inicial (homepage): 


using OpenQA.Selenium; 


namespace UITests.PageObjects 


{ 


public class HomePage 


{ 


private static IWebElement elemento; 


public static IWebElement meuLogin(IWebDriver driver) 


{ 


elemento = driver.FindElement( 


By.XPath("/html/body/div/header/div/article/section[2]/div/section/div 
/a")); 


return elemento; 





E aqui, implementação de page object para a tela de login: 


using OpenQA.Selenium; 


namespace UITests.PageObjects 


{ 


public class LoginPage 


{ 
private static IWebElement elemento; 


public static IWebElement username(IWebDriver driver) 


{ 


elemento = driver.FindElement( 
By.XPath("//*[@id='Input_Email']")); 
return elemento; 


public static IWebElement password(IWebDriver driver) 


{ 


elemento = driver.FindElement ( 
By .XPath("//*[@id='Input_Password']")); 
return elemento; 


public static IWebElement btn_login(IWebDriver driver) 
{ 


elemento = driver.FindElement( 


By.XPath("/html/body/div/div/div/div/section/form/div[5]/button")); 
return elemento; 





Por fim, o código de teste: 


using System; 

using Xunit; 

using OpenQA.Selenium; 

using OpenQA.Selenium.Chrome; 
using UITests.PageObjects; 


namespace UITests 


{ 


public class LoginTest 


{ 


IWebDriver driver = new ChromeDriver( 
Environment.CurrentDirectory); 


[Fact] 
public void testeLogin() 


{ 
driver.Navigate().GoToUrl("https://localhost:44315/"); 


HomePage.meuLogin(driver).Click(); 


LoginPage.username(driver) .SendKeys( 
"demouser@microsoft.com"); 


LoginPage.password(driver) .SendKeys("Pass@word1") ; 


LoginPage.btn_login(driver) .Click(); 





9.3 Testes Automatizados com Selenium no 
Visual Studio 


Como forma de organizar os projetos de teste dentro da solution no 
Visual Studio, pode-se criar uma pasta especifica para armazenar 
esses projetos, separando-os dos arquivos de src, conforme 
exemplo no qual foi criada a pasta tests: 





A Se o-s GE baz 


Search Solution Explorer (Ctrl+;) BP 


adl Solution 'eShopOnWeb (7 of 7 projects) 
> PP Solution Items 


b src 
4 Ss! tests 
> EI UlTests 


Figura 9.2: Organização dos testes na Solution. 


O projeto UlTests é um xUnit Test Project (NET Core), que foi 
escolhido por funcionar bem com o .NET Core, além de ser flexível 
e possuir sintaxe clara e intuitiva. 


NOTA 


Para mais informações sobre xUnit e outros frameworks de teste 
NEI. consulte: 


https://docs.microsoft.com/dotnet/core/testing/ 





Para a utilização do Selenium no Visual Studio, é necessário instalar 
as bibliotecas do Selenium WebDriver e do driver do navegador que 


será utilizado via gerenciador de pacotes NuGet. 


Nos testes de interface aqui realizados, instalaremos as seguintes 
bibliotecas: 


e Selenium.WebDriver. 
e Selenium.Chrome.WebDriver. 


Para instalar os pacotes necessários via NuGet Package Manager, 
clique em Tools -> Nuget Package Manager -> Manage NuGet 
Packages for Solution ou, ainda, selecione essa opção diretamente 
pelo Solution Explorer clicando com o botão direito do mouse na 
solution e selecionando Manage NuGet Packages for Solution. 


t View Project Build Debug Test Analyze Extensions Window Help Search (Ctrl+Q) 





9 s Get Tools and Features... 


v 


Web > IIS Express 7 






Android 
iOS 
Archive Manager... 


Connect to Database... 


= Connect to Server... 
SQL Server 
Data Lake 
| Code Snippets Manager... Ctrl+K, Ctrl+B 


Choose Toolbox Items... 


NuGet Package Manager EI Package Manager Console 
Create GUID Pê Manage NuGet Packages for Solution... 
Error Lookup & Package Manager Settings 


Spy++ 

WCF Service Configuration Editor 
External Tools... 

Command Line 

Import and Export Settings... 
Customize... 


Options... 


Figura 9.3: Acesso ao gerenciador de pacotes NuGet pelo Menu. 


-| > US Fxoress z del IT ZZ dE 3] É LẸ Live Share 
Build Solution Ctrl+Shift+B 


Rebuild Solution 


Clean Solution GO És d Sr E g | bk 





LD 
Ee 





Analyze and Code Cleanup * Search Solution Explorer (Ctrl+;) 
Batch Bulk. EI Solution ‘eShopOnWeb' (7 of 7 projects) 
Configuration Manager... > E Solution Items 
& Restore Client-Side Libraries > E src 
fA Manage NuGet Packages for Solution... 4 5] tests 
b E] uiTests 


TZ Restore NuGet Packages 


Configure Continuous Delivery to Azure... 


"A Run Tests 
Debug Tests 


Figura 9.4: Acesso ao gerenciador de pacotes pelo Solution Explorer. 


No gerenciador de pacotes NuGet, pesquise por Selenium e instale 
os pacotes necessários, especificando em qual ou quais projetos 
deverão ser instalados. No caso, vamos instalar apenas no projeto 
de teste, UlTests. 


pa | File Edit View Project Build Debug Test Analyze Tools Extensions Window Help Search (Ctrl+Q) P eSha 


ZG: | 3 - o TNT X -| Debug ~ Any CPU ~ Web A > lS Express © -| | BS Š 


Browse Installed Updates EB Consolidate D Manage Packages for Solution 











selenium x ~| © Include prerelease Package source: | nuget.org -] GO 





. . . 
EO Selenium.WebDrivel® nugetorg 


Selenium.WebDriver by Selenium Committers, 28.9M downloads v3.141.0 
NEI bindings for the Selenium WebDriver API Versions - O 








Project Version 
Selenium.Support by Selenium Committers, 22.1M downloads v3.141.0 src\ApplicationCore 


Provides support classes for Selenium WebDriver src\BlazorAdmin 




















src\BlazorShared 








src\Infrastructure 
src\PublicApi 
src\Web 
tests\UlTests 





Selenium.WebDriver.ChromeDriver by jsakamoto, 14.8 v87.0.4280.8800 
Selenium Google Chrome Driver (Win32, macOS, and Linux64) (... 
































Selenium.WebDriver.|EDriver by jsakamoto, 4.94M downloads v3.150.1.2 





Selenium Internet Explorer Driver (Win32) (this package does not make... 
Installed: not installed 


Selenium.Firefox.WebDriver by jbaranda, 4.33M downloads Version: | Latest stable 3.141.0 Install 
Selenium Firefox WebDriver Marionette (Win64) = 


EO Options 
Selenium.Chrome.WebDriver by jbaranda, 4.68M downloads v85.0.0 
Selenium Chrome WebDriver (Win32) Description 


Package Manager Console Output 





Figura 9.5: Instalagao e gerenciamento de pacotes NuGet no Visual Studio. 


Observação: após selecionar Install, serão solicitadas algumas 
confirmações das alterações que serão realizadas na solution após 
a instalação dos pacotes, as quais devem ser aceitas para a 
conclusão do processo com êxito. 


Testes no eShopOnWeb 


Desenvolveremos os seguintes casos de teste de interface 
automatizados na aplicação eShopOnWeb: 


e Login. 
e Adicionar produto ao carrinho de compras (Basket). 
e Efetuar compra (botões Checkout e Pay now). 


Para o caso de teste de Login, a figura a seguir ilustra o momento 
em que os dados de usuário e senha são inseridos via teste 


automatizado. Note que é possível visualizar a mensagem de que o 
Chrome está sendo controlado por um teste automatizado de 
software. 


JO Catalog - MicrosofteShopOnWe x + 


€ X @ localhost:44315 


Chrome is being controlled by automated test software 
eS eSHOP 
OnWeb 
Log In 


Email 


demouser@microsoft.com 


Password 


| Remember me? 


Figura 9.6: Teste automatizado sendo executado na tela de Login. 


Em Test Explorer no Visual Studio, pode-se ver que a execução do 
teste ocorreu com sucesso. 


Test Explorer 
> r>~C'e| 4404/00) A-a #- 


Test Duration 
a O UlTests (4) 37.4 sec 
4 © UlTests (4) 37.4 sec 
> GO BasketTest (1) 12.3 sec 
b D HomePageTest (1) 10.2 sec 
b OO LoginTest (1) 4.9 sec 
b Ø Tests (1) 10 sec 


Figura 9.7: Visualização dos resultados das execuções dos testes automatizados no Test 
Explorer. 


Observação: o caso de teste de Login foi detalhado no tópico 
Padrão Page Object deste capítulo. 


Os detalhes dos demais casos de teste podem ser vistos a seguir: 
Adicionar produto ao carrinho de compras (Basket). 


Utilizando a estrutura de page objects, semelhante ao que fizemos 
no caso de teste do Login, teremos uma classe page object 
representando o carrinho ( BasketPage ), com o código dos testes 
separado em outra classe ( BasketTest ) como pode ser visto a seguir. 





using OpenQA.Selenium; 


namespace UITests.PageObjects 


{ 
public class BasketPage 


{ 


private static IWebElement elemento; 


public static IWebElement adicionarProdutoAoCarrinho( 
IWebDriver driver) 


elemento = driver.FindElement( 


By.XPath("/html/body/div/div/div[2]/div[2]/form/input[1]")); 
return elemento; 


using System; 

using Xunit; 

using OpenQA.Selenium; 

using OpenQA.Selenium.Chrome; 
using UITests.PageObjects; 


namespace UITests 


{ 
public class BasketTest 


{ 


IWebDriver driver = new ChromeDriver( 
Environment.CurrentDirectory) ; 


[Fact ] 
public void testaCarrinho() 


{ 
driver .Navigate().GoToUr1("https://localhost:44315/"); 


BasketPage.adicionarProdutoAoCarrinho(driver).Click(); 


//CheckoutPage. fazerCheckout (driver) .Click(); 


//CheckoutPage.efetuarCompra(driver) .Click(); 





No código de testes acima, é possível ver que ha a chamada para o 
método adicionar produto ao carrinho da classe BasketPage , QUE 
representa o carrinho de compras. 


Comentadas, para efeito de exemplo, também estão presentes no 
código as chamadas para os métodos Fazer checkout € Efetuar 
compra , UMa vez que ambos estão relacionados ao carrinho e ao 
fluxo de compra do produto. Entretanto, é importante ressaltar que, 
para realizar checkout e pagamento (efetuar compra), é necessário 
estar logado no sistema. Veremos adiante uma forma de integrar 
login e compra no mesmo teste. 


Efetuar compra 


Para o caso do teste Efetuar compra, há a criação do page object 
CheckoutPage, que possui os métodos Fazer checkout (botão 
Checkout visível após adicionar produto ao carrinho) e Efetuar 
compra (botão Pay now da tela de Review da compra). 


using OpenQA.Selenium; 


namespace UITests.PageObjects 


{ 
public class CheckoutPage 


{ 


private static IWebElement elemento; 


public static IWebElement fazerCheckout( 
IWebDriver driver) 


elemento = driver.FindElement( 
By.XPath("/html/body/div/div/form/div/div[3]/section[2]/a")); 


return elemento; 


public static IWebElement efetuarCompra(IWebDriver driver) 


{ 


elemento = driver.FindElement( 


By.XPath("/html/body/div/div/form/div/div[3]/section[2]/input")); 
return elemento; 





O código de testes é o mesmo exemplificado pela classe BasketTest 
com as chamadas para OS métodos Fazer Checkout € Efetuar compra. 


Juntando os códigos de teste de Login aos de adicionar produto ao 
carrinho, Fazer checkout @ Efetuar compra, temos a seguinte 
representação para este exemplo: 





using System; 


using Xunit; 

using OpenQA.Selenium; 

using OpenQA.Selenium.Chrome; 
using UITests.PageObjects; 


namespace UITests 


{ 


public class Tests 


{ 


IWebDriver driver = new ChromeDriver( 


Environment.CurrentDirectory); 


[Fact] 
public void testarNavegacao() 


{ 


//Acessar URL 
driver.Navigate().GoToUrl("https://localhost:44315/"); 


//Maximizar tela 
driver.Manage().Window.Maximize(); 


//Login 
HomePage.meuLogin(driver).Click(); 
LoginPage.username(driver) .SendKeys( 
"demouser@microsoft.com"); 
LoginPage.password(driver) .SendKeys( 
"Pass@word1") ; 
LoginPage.btn_login(driver) .Click(); 


//Adicionar produto ao carrinho 
BasketPage.adicionarProdutoAoCarrinho(driver) .Click(); 


//Fazer checkout 
CheckoutPage. fazerCheckout (driver) .Click(); 


//Efetuar compra (pagar) 
CheckoutPage.efetuarCompra(driver) .Click(); 


//Fechar navegador 
driver.Quit(); 





Na tela final de execução do teste automatizado, podemos ver a 
mensagem de agradecimento pela compra: 


e C à localhost44315/Basket/Success * E 3 


Chrome is being controlled by automated test software x 


le] OnWeb demouser@microsoft.com v 


1 


SON SALE 
THIS WEEKEND 





Thanks for your Order! 


Continue Shopping... 





Figura 9.8: Visualização da última página (confirmação de compra) pelo teste automatizado 
de interface. 


9.4 Ambientes de Testes 


São ambientes dedicados a testes onde cópias da solução são 
mantidas e utilizadas para testar as alterações feitas pelo time de 
desenvolvimento. Além disso, são utilizados para validação de 
provas de conceitos e testes empíricos de performance. 


Para fazer bom proveito do potencial de seus casos de testes, ter 
ambientes de teste apartados e bem desenvolvidos, é crítico saber 


que: ter um ambiente de testes isolado de quaisquer outras 
atividades pode influenciar diretamente no processo e nos 
resultados dos testes, tornando os resultados mais confiaveis, uma 
vez que fatores externos não influenciaram sua execução. 


Ambientes de testes são construídos seguindo os pré-requisitos da 
solução testada. Tais pré-requisitos podem ser: versão de sistema 
operacional, configuração de rede, servidor de banco de dados, 
hardware, dados de teste, restrições de segurança, frameworks e 
bibliotecas, entre outros. Configurar apropriadamente os ambientes 
de teste é vital para que sejam obtidos os resultados corretos, e 
para evitar gastos desnecessários e tempo perdido com fatores que 
não são observados nos ambientes de produção. 


Tipos 


Literaturas sobre o assunto podem utilizar diferentes nomes, tipos e 
responsabilidades para ambientes de testes. Nesta obra, ambientes 
de testes serão agrupados em quatro tipos: 


Ambiente de Testes de Desenvolvimento: utilizado para testes 
manuais e/ou automatizados, cujos resultados são destinados aos 
desenvolvedores da solução. Os testes executados neste ambiente 
são destinados a validações de funcionalidades específicas: testes 
manuais geralmente são destinados a validar novas funcionalidades 
desenvolvidas, enquanto os testes automatizados são utilizados 
para identificar regressões na solução (Murray, 2006). 


Ambiente Integrado e de Desempenho: utilizado pelo time de 
desenvolvimento para verificar como as alterações feitas na solução 
a impactam como um todo quando reunidas com as alterações dos 
demais no time de desenvolvimento. Nele, também são avaliados os 
logs e as estatísticas da aplicação, de modo que possíveis 
regressões em performance e completude das funcionalidades 
(quando realizados testes de ponta a ponta) sejam identificadas. 


Ambiente de Homologagao: utilizado para os testes finais de 
aceitação antes que a solução seja implantada em produção ou 
atualizada com uma nova versão. Este é o último ambiente privado, 
e apenas utilizado pelo time de desenvolvimento (Jez e Farley, 
2010). É destinado a validar toda a aplicação, sendo um local 
seguro para testar diferentes recursos e esperar os mesmos 
resultados que seriam obtidos em produção. Como esse é um dos 
últimos ambientes de testes antes de produção, é preciso que o 
ambiente de homologação seja uma cópia do ambiente de 
produção, seguindo as mesmas configurações de hardware, 
software, segurança, certificados digitais, e outras características 
que o ambiente de produção possui (Murray, 2006). 


Ambiente de Pré-Produção: última fase antes que o ambiente de 
produção seja atualizado. Este é um tipo especial de ambiente 
utilizado para testar novas funcionalidades com um grupo reduzido 
de usuários, diferente do time de desenvolvimento, e que vai expor 
publicamente as mais recentes alterações (Jez e Farley, 2010). Uma 
das vantagens deste ambiente é que ele não possui as mesmas 
exigências de disponibilidade que o ambiente de produção. Isso 
permite que erros nesse ambiente não possuam o mesmo impacto 
que os do ambiente em produção, o que permite aos times de 
desenvolvimento falhar e poder se recuperar antes que os erros 
sejam expostos em produção. 


A passagem de um ambiente de testes para outro depende da 
evolução da maturidade do código sendo testado: quando todos os 
testes esperados em um ambiente forem realizados, e os resultados 
obtidos forem os esperados, então a versão do código sendo 
testada estará pronta para o próximo nível de testes no próximo 
ambiente de testes. 


A imagem a seguir apresenta os ambientes de testes sugeridos e a 
evolução de um ambiente para o outro conforme a maturidade do 
código sendo testado cresce, a partir dos resultados satisfatórios 
dos testes de cada ambiente. 


Ao final de todos os testes, espera-se entao que a maturidade do 
código sendo testado apresente resultados suficientes para que o 
ambiente de produção seja atualizado sem riscos de regressões 
e/ou novos erros (Freeman, Steve, e Nat Pryce, 2012). 


Ambiente de Produção 


Ambiente de Pré-Produção 
Maturidade 


Do Código Ambiente de Homologação 
Sendo Testado 


Ambiente de Testes integrados e de Desempenho 


Ambiente de Testes de Desenvolvimento 


Figura 9.9: Sequência de Ambientes de Testes a serem utilizados para validar a maturidade 
do código produzido antes de atingir o Ambiente de Produção. 


Manutenção 


Todos os tipos de ambientes de testes vão exigir algum tipo de 
manutenção, seja a atualização do sistema operacional, atualização 
de certificados digitais, adição de novos recursos, remoção de 
recursos existentes, e outras tantas tarefas necessárias para que 
todos os ambientes permaneçam saudáveis e úteis para os testes 
realizados pelo time de desenvolvimento. 


Os recursos computacionais exigidos por esses ambientes estão 
relacionados às características e às responsabilidades dos 
ambientes de testes. Por exemplo, ambientes utilizados para testes 
de desempenho exigirão um hardware semelhante ao utilizado nos 
ambientes de produção, pois se deseja reproduzir o desempenho 
dos clientes finais. Ao mesmo tempo, ambientes de teste de 
desenvolvimento não precisarão do mesmo hardware, pois os testes 
ali executados são de curta duração e visam validar a assertividade 
e completude das mais recentes alterações. 


Quanto mais próximo do ambiente de produção, maior será a 
semelhança do ambiente de teste com as configurações finais de 
hardware e software de produção. 


Dados 


Muitos times de desenvolvimento costumam copiar dados de 
produção para seus ambientes de testes para que possam detectar 
os mesmos problemas encontrados em produção. Ao copiar dados 
de produção para os ambientes de testes, algumas práticas devem 
ser seguidas: 


e Remova dados privados ou que possam ser utilizados para 
identificar os clientes que geraram essas informações. 

e Remova dados desnecessários para os testes. 

e Crie tarefas automatizadas que copiem os dados de produção 
de tempos em tempos para que cada vez menos tarefas 
manuais sejam necessárias. 


Privacidade é sempre a principal preocupação quando lidamos com 
dados de produção. Dados sigilosos devem ser removidos ou 
ofuscados. Manter a privacidade de clientes deve ser sempre a 
maior preocupação quando dados de produção são manipulados. 


Exemplos 


Para a criação de um ambiente de homologação, reutilizaremos o 
script compartilhado no capítulo 1. O script previamente 
compartilhado teve alguns ajustes a fim de permitir a 
parametrização do nome do ambiente de teste sendo criado. 


O script a ser utilizado será o seguinte: 





param ([Parameter(Mandatory = $true) ]$environment, 
[Parameter(Mandatory = $true)]$username, [Parameter(Mandatory = 
$true) |gazuresubscription) 


$azureuser = az ad user list ` 
--display-name $username” 
--query [0].userPrincipalName 


$resourcegroup = "rg-eshoponweb-$environment” 
$storageaccountname = "stdeploy$environment" 
$storagecontainername = "stcdeploy$environment" 
$sqlservername = "sql-eshoponweb-$environment" 
$scalesetname = "vmss-web-$environment" 
gautoscalename = "vmssas-web-$environment" 
$dnsName = "eshoponweb-$environment” 
$adminusername = "eshopadmin" 


$sqladminpassword = "s3nh@Comple*4" 
az login 


# Resource Group 
az group create -l brazilsouth -n $resourcegroup ` 
--subscription $azuresubscription 


# Storage 

az storage account create --subscription $azuresubscription ` 
-g $resourcegroup -n $storageaccountname -1 brazilsouth ` 
--sku Standard_LRS --encryption-services blob 


az ad signed-in-user show --query objectId -o tsv | 

az role assignment create ~ 

--role "Storage Blob Data Contributor" --assignee $azureuser ` 

--scope 
"/subscriptions/$azuresubscription/resourceGroups/$resourcegroup/provi 
ders/Microsoft.Storage/storageAccounts/$storageaccountname" 


az storage container create -n $storagecontainername ` 
--account-name $storageaccountname --public-access off ` 
--auth-mode login 


az storage share create -n products --quota 10 ` 
--account-name $storageaccountname 


az storage share create -n dataprotection --quota 10 ` 
--account-name $storageaccountname 


# Azure SQL Database 

az sql server create --subscription $azuresubscription ~ 
-g $resourcegroup -n $sqlservername -l brazilsouth ` 
--admin-user $adminusername --admin-password $sqladminpassword 


az sql server firewall-rule create -g $resourcegroup ` 
-n "sql-firewall-rule" -s $sqlservername ` 
--start-ip-address 0.0.0.0 --end-ip-address 0.0.0.0 


az sql db create -g $resourcegroup ` 
-n Microsoft.eShopOnWeb.CatalogDb -s $sqlservername -e Basic 


az sql db create -g $resourcegroup ` 
-n Microsoft.eShopOnWeb.Identity -s $sqlservername -e Basic 


# VM Scale Set 
az vmss create --subscription $azuresubscription ` 

-g $resourcegroup -n $scalesetname --image UbuntuLTS ` 
--upgrade-policy-mode automatic ` 


--admin-username $adminusername --generate-ssh-keys 


## DNS Name 
$publicip = az network public-ip list -g $resourcegroup ~ 


--query "[?contains(name, '$scalesetname')].name 
| ConvertFrom-Json 


az network public-ip update -g $resourcegroup ` 
-n $publicip --dns-name $dnsName 


## Application deployment 
az vmss extension set -g $resourcegroup -n CustomScript ~ 
--publisher Microsoft.Azure.Extensions --version 2.0 ` 


--vmss-name $scalesetname ~ 
--settings ".\script-config-$environment.json" ` 


--protected-settings ".\protected-config-$environment. json" 


## Load Balancer configuration 

$loadbalancer = az network lb list -g $resourcegroup ` 
--query "[?contains(name, '$scalesetname')].name" ` 
| ConvertFrom-Json 


az network lb probe create -g $resourcegroup -n healtchecks ` 
--lb-name $loadbalancer --protocol http 
--port 8@ --path /health 


az network lb rule create -g $resourcegroup -n lbr-web-ch-001 
--lb-name $loadbalancer ` 
--backend-pool-name "$($scalesetname)LBBEPool” ` 
--backend-port 80 --frontend-ip-name loadBalancerFrontEnd ` 
--frontend-port 80 --protocol tcp --probe-name healthchecks 


## Autoscale 

az monitor autoscale create -g $resourcegroup -n $autoscalename ~ 
--resource $scalesetname ~ 
--resource-type Microsoft.Compute/virtualMachineScaleSets ` 
--min-count 2 --max-count 3 --count 2 


az monitor autoscale rule create -g $resourcegroup ` 
--autoscale-name $autoscalename ` 
--condition "Percentage CPU > 70 avg 5m" --scale out 1 


az monitor autoscale rule create -g $resourcegroup ~ 
--autoscale-name $autoscalename ` 
--condition "Percentage CPU < 30 avg 5m" --scale in 1 





Serão obrigatórios três parâmetros para a execução desse script: 


e environment : nome do ambiente de testes. Para a criação do 
ambiente de testes, utilize homolog. 

e username : nome do usuário que realizará a operação. 

e azuresubscription : Azure Subscription ID é onde os recursos 
serão criados. 


9.5 Reconfiguragao CI/CD 


No capítulo 2, criamos um procedimento de Continuous Integration, 
porém sem a execução dos testes. Neste momento, já temos o 
projeto de testes em nossa solução, por isso vamos alterar o arquivo 
YAML eshoponweb-ci.yml para executar automaticamente os testes 
unitários. Precisamos adicionar mais um passo de Test conforme o 
seguinte YAML: 


name: eshoponweb-ci 


on: 
push: 
branches: [ master ] 
pull request: 
branches: [ master ] 


jobs: 
build: 


runs-on: ubuntu-latest 


steps: 
- uses: actions/checkout@v2 


name: Setup .NET Core 
uses: actions/setup-dotnet@v1 
with: 

dotnet-version: 3.1.301 


name: Install dependencies 
run: dotnet restore 


name: Build API 
run: dotnet build src/PublicApi/PublicApi.csproj 
--configuration Release --no-restore 


name: Build Web 
run: dotnet build src/Web/Web.csproj 


--configuration Release --no-restore 


name: Test 


run: dotnet test UnitTests/UnitTests.csproj 
--no-restore --verbosity normal 





Já no workflow de Continuous Delivery, arquivo eshoponweb-cd.yml, 
temos que repetir esse mesmo procedimento. 


9.6 Resumo 


Neste capitulo, abordamos os conceitos de ambientes de testes, 
bem como alguns exemplos de implementação de tipos de testes: 


e Testes de interface funcionais utilizando o framework do 
Selenium. 
e Conceitos de ambientes de testes, seus tipos e benefícios. 


CAPITULO 10 
Desacoplamento 


Escrito por Victor Zamora 


CENARIO 


Aplicações evoluem e para que uma aplicação possa evoluir é 
necessário que ela possua características de flexibilidade e 
manutenibilidade, isso nos ajuda a utilizar da melhor forma os 
recursos da nuvem e atender a novas necessidades de negócio 
que não existiam quando ela foi construída. Um importante 
componente a ser levado em consideração no desenho da 


solução para atender a esses requisitos é o baixo acoplamento 
entre as suas partes. 


Neste capítulo, vamos abordar os seguintes assuntos: 


e Interfaces e injeção de dependências. 

e Armazenamento de arquivos na nuvem. 
e REST APIs. 

e Clientes Web. 





10.1 Reduzir o acoplamento 


O nível de acoplamento determina o quanto as partes do código são 
dependentes umas das outras e, principalmente, o quão simples é 
substituir uma determinada dependência por outra que implemente 


a mesma funcionalidade de maneira diferente, sem impacto no 
restante do codigo. 


Para que isso aconteça é importante que os componentes de uma 
aplicação consigam conversar entre si de uma forma previamente 
definida. Isso pode ocorrer dentro do mesmo processo ou entre 
processos, inclusive remotos. 


Dentro de um mesmo processo, essa comunicação é feita 
normalmente através de interfaces, enquanto a comunicação entre 
eles exige a utilização de um protocolo comum (na verdade, na 
maioria das vezes, um conjunto de protocolos comum) de ambos os 
processos. 


Vamos começar falando sobre interfaces no contexto da linguagem 
CH e mais à frente abordaremos o uso de HTTP e APIs REST para 
comunicação entre aplicações. 


10.2 Interfaces 


Ao desenhar soluções de software, uma característica desejável é 
que haja um baixo nível de acoplamento entre os componentes da 
solução, ou seja, que os componentes possam ser conectados e 
reconectados de forma livre para simplificar a evolução do software. 


Para que isso aconteça, o ideal é que essas conexões ocorram 
através de interfaces. Mas o que é uma interface? 


Imagine as portas USB do computador, é possível usá-las para 
conectar um teclado ou mouse externo, dispositivos de 
armazenamento, impressoras, telefones celulares, entre outros. Em 
uma visão simples, o USB é a interface comum que permite 
conectar todos esses dispositivos, definindo uma conexão comum e 
a maneira como eles conversam entre si. 


No código, as interfaces desempenham esse mesmo papel 
definindo pontos de conexão e regras para a comunicação entre os 
diversos componentes de uma solução, seja essa comunicação 
local ou remota. 


Em linguagens orientadas a objetos, como C#, pode-se usar 
interfaces e classes para desacoplar componentes abstratos de 
suas implementações concretas, enquanto em aplicações 
distribuídas é comum utilizar protocolos para que as partes da 
solução conversem entre si usando a conexão de rede. O HTTP é 
um protocolo amplamente utilizado nesse sentido, combinado a 
representações de dados, como XML ou JSON para implementação 
de APIs com acesso via Web. 


Começando por um exemplo simples com interfaces: 


int[] primes = (1,2,3,7,11,13,17,19, 23, 29}; 
printData(primes); 


void printData(int[] data){ 


for(int i = Q;i<data.Length;i++){ 
Console.wWrite($"{data[i]},"); 


//vai exibir: 1,2,3,7,11,13,17,19, 23,29, 





O exemplo anterior é fortemente acoplado. O nosso método imprime 
todos os números de um array de inteiros. Se quiséssemos utilizar o 
mesmo código para imprimir todos os caracteres de uma string ou 
um array de bytes, teríamos que ter uma versão praticamente igual 
para cada tipo de dado. E, se cada um desses tipos de dados 
implementasse uma interface comum, poderíamos utilizar o mesmo 
código. 


Essa interface no .NET Framework existe e é chamada 
IEnumerable<T> . Ela nos permite enumerar tipos que representem 
sequências ou conjuntos. Para tornar o nosso código menos 
acoplado, bastaria escrevê-lo da seguinte forma. 


int[] primes = {1,2,3,7,11,13,17,19, 23, 29}; 
string[] words = {"Isso", "parece", "interessante."}; 


printEnumerable(primes) ; 
printEnumerable(words) ; 
printEnumerable("Esse código tem baixo acoplamento."); 


public void printEnumerable<T>(IEnumerable<T> data) { 
foreach(T item in data){ 
Console.write($"{item},"); 
} 


Console.WriteLine(); 


//vai exibir: 

// 1,2,3,7,11,13,17,19,23,29, 

// Isso,parece,interessante., 

II EEEa, 5€,0,0,;1,8,0, 5,4; ml, 

1! sD58;15X505: 59;€;0,D;1,a;M,6;hn5€50555 





Por fim, interfaces definem um conjunto de métodos que uma classe 
deve obrigatoriamente implementar sem determinar como será essa 
implementação. Mais adiante veremos como a aplicação 
eShopOnWeb utiliza interfaces para promover o desacoplamento 
entre suas partes. 


10.3 Injeção de dependências 


A injeção de dependências é uma técnica por meio da qual o 
controle da criação dos objetos é feita externamente às classes, que 
passam a receber instâncias concretas de classes que 
implementam interfaces esperadas. 


Ela é feita através de um componente conhecido como injetor ou 
contêiner de dependências, que mantém informações sobre quais 
classes devem ser injetadas no código e qual o ciclo de vida desses 
objetos. 


No ASP.NET Core, o construtor das classes é utilizado para que as 
dependências sejam injetadas no código, conforme demonstrado no 
exemplo a seguir. 


public class BasketViewModelService : IBasketViewModelService 


{ 
private readonly IAsyncRepository<Basket> _basketRepository; 
private readonly IUriComposer _uriComposer; 


private readonly IAsyncRepository<CatalogItem> _itemRepository; 


public BasketViewModelService( 
TAsyncRepository<Basket> basketRepository, 
IAsyncRepository<CatalogItem> itemRepository, 
IUriComposer uriComposer) 
{ 
_basketRepository = basketRepository; 
_uriComposer = uriComposer; 
_itemRepository = itemRepository; 





Observe que os parametros e as variaveis privadas que guardam os 
objetos são declarados usando o tipo de dados das interfaces. Em 
nenhum ponto do código se utiliza um tipo concreto para referenciar 
dependências injetadas. 


No ASP.NET Core, as dependéncias sao registradas na classe 
Startup dentro do método ConfigureServices através de 


IServicesCollection : 


public void ConfigureServices(IServiceCollection services) { 


services .AddScoped<IBasketViewModelService, 
BasketViewModelService>(); 

services.AddScoped<CatalogViewModelService>(); 

services.AddScoped<ICatalogItemViewModelService, 
CatalogItemViewModelService>(); 





Note no exemplo como as interfaces sao associadas as suas 
implementações concretas, que serão criadas em tempo de 
execução. 


Ao registrar uma dependência define-se qual o ciclo de vida que o 
objeto terá na aplicação. Iservicescollection define um conjunto de 
métodos para o registro de dependências de acordo com o seu 
tempo de vida. Esses métodos podem ser: 


e AddTransient : Uma nova instância será criada e injetada para 
cada classe que tenha declarado uma dependência para aquele 
tipo de dado. 


e AddScoped : Classes que participam de um mesmo escopo 
recebem as mesmas instâncias das dependências declaradas. 
No ASP.NET MVC, todas as requisições iniciam um novo 
escopo e, portanto, todas as classes envolvidas em uma 
mesma requisição compartilham as mesmas instâncias de 
classes declaradas como scoped. 


e AddSingleton : Classes singleton possuem uma única instância 
utilizada por toda a aplicação. 


10.4 Como o eShopOnWeb usa interfaces e 
injeção de dependências 


O eShopOnWeb utiliza a injeção de dependências para construir 
uma estrutura com baixo acoplamento entre as diversas partes da 
solução. 


O projeto Applicationcore concentra as definições do modelo de 
negócios e, nele, são definidas as interfaces que representam os 
principais componentes da solução, as entidades de dados e os 
serviços que implementam as regras de negócio. 


A aplicação web é responsável apenas pela orquestração dos 
serviços a partir das requisições HTTP feitas pelo cliente e da 
composição das respostas a essas requisições com os dados 
retornados pelos diversos serviços. 
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Figura 10.1: Projetos da solução eShopOnWeb 


As entidades relacionadas às funções de negócio seguem o 
princípio de ignorância de persistência, ou seja, as classes não têm 
código específico relacionado à persistência dos dados. 


As propriedades e anotações serão usadas para a criação da base 
de dados a partir do código e para validação de entradas de dados, 
porém a persistência em si pode ser feita em qualquer repositório. 


O código responsável pela persistência dos dados esta no projeto 
Infrastructure , que utiliza o Entity Framework Core, porém isso é 
transparente tanto para o código no applicationcore quanto para a 
aplicação Web. 


O seguinte diagrama descreve as camadas da aplicação: 


Dependência em Compilação 


Interface com Usuário 





Dependência opcional em Compilação 





Figura 10.2: Diagrama de camadas da aplicação 


Vamos tomar como exemplo a interface IBasketservice : 


namespace Microsoft .eShopOnWeb.ApplicationCore. Interfaces 


{ 


public interface IBasketService 
{ 
Task TransferBasketAsync(string anonymousId, 
string userName) ; 
Task AddItemToBasket(int basketId, 


int catalogItemId, decimal price, int quantity = 1); 
Task SetQuantities(int basketId, 
Dictionary<string, int> quantities) ; 
Task DeleteBasketAsync(int basketId) ; 
} 
} 





Essa interface define as operações relacionadas a cesta de 
compras, como adicionar, remover ou alterar a quantidade de itens 
na cesta de compras. 


A interface define operações, mas não as implementa. Elas são 
implementadas na classe BasketService , que aplica regras de 
negócio e efetua a persistência da informação através de uma 
instância de IAsyncRepository<Basket> injetada através do construtor. 


namespace Microsoft.eShopOnWeb.ApplicationCore. Services 
{ 
public class BasketService : IBasketService 
{ 
private readonly IAsyncRepository<Basket> _basketRepository; 
private readonly IAppLogger<BasketService> _logger; 


public BasketService( 
IAsyncRepository<Basket> basketRepository, 
IAppLogger<BasketService> logger) 
{ 
_basketRepository = basketRepository; 
_logger = logger; 
} 


public async Task AddItemToBasket( 
int basketId, int catalogItemId, 
decimal price, int quantity = 1) 


var basketSpec=new BasketWithItemsSpecification(basketId) ; 

var basket=await 
_basketRepository.FirstOrDefaultAsync(basketSpec) ; 

Guard.Against.NullBasket(basketId, basket); 


basket .AddItem(catalogItemId, price, quantity); 


await _basketRepository.UpdateAsync(asket) ; 





Como o Basketservice conhece apenas a interface IAsyncRepository , 
é fácil substituir a implementação por outra e, dessa forma, substituir 
o repositório de dados por outra implementação sem impacto no 
código que implementa as regras de negócio. 


A implementação atual da cesta de compras, por exemplo, pode ser 
substituída por outra que utilize cache distribuído para manter as 


informações em memoria e acelerar o acesso aos dados ou por uma 
que substitua o repositório de dados relacional por um banco de 
dados NoSQL. 


10.5 REST APIs 


Os dados e a lógica de negócio podem ser expostos através de 
APIs que permitam integração com outras aplicações, bem como a 
possibilidade de desenvolver clientes interativos baseados em 
browser ou aplicações móveis que consumam os mesmos dados e 
serviços. 


Esse tipo de API se baseia nas semânticas do protocolo HTTP para 
possibilitar o acesso a recursos no servidor identificáveis através de 
URLs, e as ações são definidas pelos verbos HTTP, como GET, 
POST, PUT ou DELETE. Os dados podem ser devolvidos em 
formatos baseados em texto, como JSON, XML e CSV ou formatos 
binários, como imagens ou arquivos PDF. 


Na solução eShopOnWeb, temos no projeto publicapi uma API que 
permite gerenciar os itens do catálogo através de endpoints 
expostos para aplicações. 


Os endpoints são descritos com o auxílio do framework Swagger, 
atualmente chamado de OpenApi, que é um protocolo aberto para 
documentação de APIs Web tanto em formato legível para pessoas 
quanto em formato JSON para suporte a ferramentas de 
desenvolvimento e SDKs. 


Ao executar o projeto publicapi no Visual Studio, automaticamente 
o browser é aberto no endereço https://localhost: 
{porta}/swagger/index.html , que é o endereço da documentação em 
HTML para a API. 
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Figura 10.3: Exemplo de documentação Swagger 


Além da pagina de documentação, pode-se experimentar APIs Web 
utilizando ferramentas que permitam construir e executar 
requisições HTTP de forma interativa, tais como, Telerik Fiddler, 
Postman ou HTTP REPL, uma ferramenta .NET Core baseada em 
linha de comando e multiplataforma para testar APIs. Também é 
possível utilizar CURL em Linux ou Invoke-WebRequest em 
PowerShell para testar APIs REST. 


Como exemplo, o comando a seguir vai retornar os dez primeiros 
itens do catálogo em formato JSON se executado dentro de uma 
janela do PowerShell: 


(wget "https://localhost:{porta}/api/catalog-items? 


PageSize=10&PageIndex=0").Content 





O resultado esperado é o JSON a seguir: 


"catalogItems": [ 
{ 


"id": 5, 
"name": “Roslyn Red Sheet", 
"description": "Roslyn Red Sheet", 


"price": 8.5, 

"pictureUri": "/images/products/5.png", 
"catalogTypeId": 3, 

"catalogBrandId": 5 


"id": 10; 

"name": ".NET Foundation Sheet", 
"description": ".NET Foundation Sheet", 
"price": 12, 

"pictureUri": "/images/products/10.png", 
"catalogTypeId": 3, 

“catalogBrandId": 2 


J, 
"pageCount": 2 





Observe que o comando Invoke-webRequest NO PowerShell possui 
mais de um nome, podendo ser executado também como: weet, 


curl OU iwr. 


eShopOnWeb REST API 


A API pública do eShopOnWeb tem como foco a manutenção do 
catálogo de produtos. Ela também oferece um endpoint para 
autenticação de usuários que retorna um token que as aplicações 
utilizam para executar requisições em nome do usuário autenticado. 


Um cer HTTP na URL /api/catalog-items listará os itens do catálogo. 
Pagesize € PageIndex São parâmetros dessa chamada e informam a 
quantidade de itens por página e a primeira página de itens a ser 
exibida respectivamente. 


GET é O verbo associado com a obtenção de conteúdo no protocolo 
HTTP e não provoca efeitos secundários sobre os dados em sua 
execução. GET é sempre uma operação de leitura. Para incluir um 
novo item no catálogo, deve-se executar um post , para alterar um 
item já existente, um pur e, para excluir um item, DELETE, como 
pode ser visto na documentação em Swagger. 


A API também possui dois endpoints referentes ao gerenciamento 
de catálogo, /api/catalog-types © /api/catalog-brands , QUE permitem 
obter os tipos de itens e as marcas respectivamente. 


O ultimo endpoint da API, /api/authenticate , é usado para 
autenticação de usuários. Ele recebe um POST informando o nome 
de usuario e senha e tem como resposta, caso usuario e senha 
sejam válidos, um token que pode ser usado para autorização na 
aplicação além de informações sobre a situação da conta do 
usuário. 


O projeto publicapi faz uso das mesmas entidades de negócio e 
classes de manipulação de dados declaradas nos projetos 
ApplicationCore @ Infrastructure , funcionando como mais uma 
interface para as mesmas regras e objetos de negócio. Como 
exemplo, podemos ver como a instância de IAsyncRepository é 
injetada na classe que traz os itens do catálogo: 


//Startup.cs 


services.AddScoped(typeof(IAsyncRepository<>), 
typeof(EfRepository<>)); 


//ListPage.cs 


public ListPaged(IAsyncRepository<CatalogItem> itemRepository, 
IUriComposer uriComposer, IMapper mapper) 


_itemRepository = itemRepository; 





Clientes Blazor acessando a API Web 


Clientes que fazem uso de uma API Web devem ser capazes de 
preparar e executar requisições usando o protocolo HTTP. 
Considerando-se que HTTP é um protocolo de aplicação sobre os 
protocolos de rede, qualquer linguagem de programação deve ser 
capaz de prover essa funcionalidade com maior ou menor grau de 
dificuldade. 


O .NET oferece suporte para executar requisições HTTP através da 
Classe HTTPClient . 


O eShopOnWeb traz uma aplicação cliente para o gerenciamento 
dos itens do catálogo baseada em Blazor, um framework que 
permite desenvolver aplicações em C# que são executadas em 
browsers que suportam WebAssembly. 


O código no browser acessa os dados de catálogo através da API 
REST mantendo as bases de dados protegidas atrás de serviços. 


No arquivo Program.cs , No projeto Blazoradmin , pode ser vista a 
configuração da injeção de dependências da classe HTTPClient : 


public static async Task Main(string[] args) 
d 


var builder = WebAssemblyHostBuilder.CreateDefault (args); 


builder.Services.AddScoped(sp => new HttpClient() 
{ 


BaseAddress = new Uri( 
builder.HostEnvironment.BaseAddress 


) 
}); 


builder.Services.AddScoped<HttpService>(); 





Uma instância de HTTPclient é injetada no construtor da classe 
HttpService , que funciona como um helper executado pelas demais 
classes de serviço, evitando a redundância do código que suporta 
as chamadas HTTP e serialização e desserialização de dados em 
formato JSON usados nas requisições e respostas: 





//HttpService.cs 


public class HttpService 


{ 
private readonly HttpClient _httpClient; 


private readonly string _apiUrl; 


public HttpService(HttpClient httpClient, BaseUrlConfiguration 
baseUrlConfiguration) 


_httpClient = httpClient; 
_apiUrl = baseUrlConfiguration.ApiBase; 


} 


public async Task<T> HttpPost<T>(string uri, object dataToSend) 
where T : class 


var content = ToJson(dataToSend); 


var result = await 
_httpClient.PostAsync($”{_apiUrl}{uri}”’, content); 
if (!result.IsSuccessStatusCode) 


{ 


return null; 


return await FromHttpResponseMessage<T>(result) ; 


//CatalogItemService.cs 
public class CatalogItemService : IcatalogItemService 
{ 
public async Task<CatalogItem> Create( 
CreateCatalogItemRequest catalogItem) 


return (await 
_httpService.HttpPost<CreateCatalogItemResponse> 


(“catalog-items”,mcatalogItem) ).CatalogItem; 





A classe HttpClient possui métodos para requisições baseados nos 
verbos HTTP ( GetAsync , PostAsync , PutAsync , DeleteAsync ) como 
pode ser visto no exemplo acima, que executa um POST enviando 
conteúdo para um endpoint informado como parâmetro. 


Note que os dados enviados à API são passados como parâmetro 
do tipo object ( dataTosend ) que são serializados para JSON que é o 
formato esperado pela API do eShopOnWeb (objeto content A 
conversão de objetos para JSON e de JSON para objetos é feita 
através da classe JsonSerializer : 


private StringContent ToJson(object obj){ 
return new StringContent (JsonSerializer.Serialize(obj), 
Encoding.UTF8, “application/json”) ; 


private async Task<T> FromHttpResponseMessage<T>( 
HttpResponseMessage result) 


return JsonSerializer.Deserialize<T>( 
await result.Content.ReadAsStringAsync(), 
new JsonSerializerOptions{ 


PropertyNameCaseInsensitive = true 





Para acessar a funcionalidade de administração, faça o login como 
admin@microsoft.com, utilize a senha Pass@word1 e acesse 
Admin no menu do usuário: 


admin@microsoft.com v O, 
ADMIN 
MY ORDERS 


MY ACCOUNT 


LOG OUT [& 





Figura 10.4: Menu do usuário 


A página de administração do catálogo pode ser vista a seguir. Do 
ponto de vista do usuário final não há diferença entre essa área 
administrativa e qualquer outra aplicação Web, porém internamente 
trata-se de um componente escrito em C# executado dentro do 
browser e que se comunica com o back-end da aplicação através de 
uma API Web. 


|” Admin - Catalog - MicrosofteSh x | + = o x 
e O A https://localhost:44315/admir at dS FP Ou 


eShopOnWeb Admin About eShopOnWeb 


A Home Manage Product Catalog 


Item Type Brand Id Name Description Price Actions 


T-Shirt NET 1 NET Bot Black Sweatshirt .NET Bot Black Sweatshirt 19.50 


Mug INET 2 MET Black & White Mug .NET Black & White Mug 8.50 
T-Shirt Other 3 Prism White T-Shirt Prism White T-Shirt 12.00 


T-Shirt «NET 4 -NET Foundation Sweatshirt -NET Foundation Sweatshirt 12.00 


Sheet Other 5 Roslyn Red Sheet Roslyn Red Sheet 8.50 





Figura 10.5: Manutengao do catalogo - Blazor Web Assembly 


O Blazor usa o mesmo engine de geração de paginas Web utilizado 
pelo ASP.NET MVC chamado Razor, que utiliza um mix de CÊ e 
HTML para geração dinâmica de conteúdo. 


O código a seguir é parte da página que lista o catálogo de 
produtos. Note como o caractere @ marca a passagem de HTML 
para CÊ: 


//BlazorAdmin/Pages/CatalogItemPage/list.razor 


@page "/admin" 

@attribute Authorize(Roles= 
BlazorShared.Authorization.Constants.Roles.ADMINISTRATORS) | 

@inherits BlazorAdmin.Helpers.BlazorComponent 

@namespace BlazorAdmin.Pages.CatalogItemPage 


<hi>Manage Product Catalog</h1> 


@if (catalogItems == null) 
{ 
<Spinner></Spinner> 
} 
else 
{ 
<p class="esh-link-wrapper"> 
<button class="btn btn-primary" @onclick="@(CreateClick)"> 
Create New 
</button> 
</p> 


<table class="table table-striped table-hover"> 
<thead> 
<tr> 
<th></th> 
<th>Item Type</th> 
<th>Brand</th> 
<th>Id</th> 
<th>Name</th> 
<th>@nameof (CatalogItem.Description)</th> 
<th>@nameof (CatalogItem.Price)</th> 
<th>Actions</th> 





Para acessar a funcionalidade de administração do catálogo, é 
necessário executar as aplicações web € Publicapi ao mesmo 
tempo. A forma mais simples para fazer isso em tempo de 


depuração é configurar a solução no Visual Studio para iniciar 
múltiplos projetos (Menu Project -> Set Startup Projects...). 





Solution 'eShopOnWeb' Property Pages ? x 
| 4 Common Properties © Current selection 
Startup Project Ze E 
© Single startup project 
Project Dependencies Ore! E 
Code Analysis Settings Web 
Debug Source Files ES ; E 
> Configuration Properties (9) Multiple startup projects: 
Project Action 
ApplicationCore None K 
BlazorAdmin None SG 
BlazorShared None b 
Infrastructure None a 
PublicApi Start M 
Web Start ” 








Figura 10.6: Iniciar múltiplos projetos no Visual Studio 


WebAssembly (abreviado como Wasm) é um formato de instruções 
binárias para uma máquina virtual baseada em pilha. Wasm é 
desenhado como um formato de compilação portável para 
linguagens de programação, possibilitando a distribuição de 
aplicações na web em clientes ou servidores. 


Blazor pode ser usado de duas formas diferentes, Blazor 
WebAssembly, como é o caso da implementação no eShopOnWeb, 
ou Blazor Server. 


No modelo de WebAssembly, o código é distribuído em formato 
binário e executado diretamente no browser enquanto, no Blazor 
Server, o código é executado no servidor de forma assíncrona e as 


atualizações de pagina são enviadas ao browser usando SignalR, 
um framework que permite fazer requisições do servidor para o 
cliente. 


Single Page Applications 


Single Page Applications (SPA) são aplicações que combinam 
HTML, CSS e JavaScript e que são executadas diretamente no 
browser sem usar o servidor para navegar entre páginas. 


A principal diferença entre Blazor WebAssembly e SPAs é que 
essas últimas utilizam recursos que estão disponíveis nos browsers 
a várias versões sendo, portanto, mais indicadas quando se deseja 
atingir um público maior. 


Dado o volume de tecnologias que são combinadas para a criação 
de aplicações SPA é recomendado que se use frameworks para 
maior produtividade no desenvolvimento. 


Alguns frameworks SPA bastante conhecidos são AngularJS, 
React e Vue.js. 


O AngularJS define um framework MVC para aplicações enquanto 
React é focado no desenvolvimento de componentes e o Vue.js se 
posiciona como um framework progressivo onde as funcionalidades 
podem ser acrescentadas de acordo com a necessidade, ou seja, 
cada framework tem as suas características e não cabe aqui uma 
análise aprofundada de cada um deles. 


Independente de qual seja o framework escolhido, o suporte a 
chamadas HTTP é parte da implementação dos browsers e é 
disponibilizado através do objeto xmiHttpRequest , e OS frameworks de 
programação costumam acrescentar abstrações para simplificar o 
acesso a APIs REST. 


Vamos tomar como exemplo um cliente hipotético feito em 
AngularJS, acessando a publicapi através de chamadas HTTP 
como faz O Blazoradmin . 


Sendo AngularJS um framework que implementa o pattern MVC, 
temos o controller que é o responsável pelo encadeamento dos 
fluxos do usuário, as views que fazem a apresentação dos dados e 
os modelos que são as entidades de dados. 


Uma prática recomendada em AngularJS é que os acessos a dados 
externos sejam implementados em classes de serviço, como: 


import { Injectable } from '(dangular/core'; 
import { CatalogItem, CatalogResponse} from './catalog'; 
import { HttpClient, HttpHeaders, HttpParams} 
from ‘@angular/common/http' ; 
import { Observable, of } from 'rxjs'; 


@Injectable({ 
providedIn: 'root' 


}) 
export class CatalogService { 


private catalogUrl = 
“https://localhost:5099/api/catalog-items'; 


constructor( 
private http:HttpClient 


) {9} 


public getPagedItems(): Observable<CatalogResponse> { 
const options = {params: new HttpParams() 
.set('PageSize','100')} 
return this.http.get<CatalogResponse>( 
this.catalogUrl, options); 





Esse código implementa um serviço em AngularJS. Uma de suas 
características é o uso de Injectable , que configura a injeção de 


dependências no AngularJS. 


O serviço recebe através do construtor uma instância de Httpclient 
da biblioteca @angular/common/http e utiliza essa instância para 
executar chamadas HTTP para um endpoint. Nesse exemplo, o 
código executa um T para a URL que retorna os itens do 
catálogo. 


A resposta é mapeada para a interface catalogResponse , que é 
definida como a seguir: 


export interface CatalogItem{ 
id: number; 
name: string; 
description: string; 
price: number; 
pictureUri: string; 
catalogTypeId: number, 
catalogBrandId: number 


export interface CatalogType{ 
id:number; 
name: string; 


export interface CatalogBrand{ 
id:number; 
name: string; 


export interface CatalogResponse{ 
catalogItems: CatalogItem[], 


pageCount: number 





O CatalogService @ injetado na classe catalogComponent , que executa 
o método, recebe o modelo retornado e retorna os dados para a 
view através da propriedade items : 


import { Component, OnInit } from '@angular/core' ; 
import { CatalogItem, CatalogResponse} from '../catalog'; 
import { CatalogService } from '../catalog.service' ; 
@Component ({ 
selector: 'app-catalog', 
templateUrl: './catalog.component.html', 
styleUrls: ['./catalog.component.css'] 


}) 


export class CatalogComponent implements OnInit { 


items: CatalogItem[]; 


constructor(private catalogService: CatalogService) { } 


getPagedItems(): void { 
this.catalogService.getPagedItems() 
.subscribe((response:CatalogResponse) => 
this.items = response.catalogItems); 


ngOnInit(): void { 
this.getPagedItems(); 
} 
} 





De forma semelhante a outros frameworks, AngularJS utiliza um 
misto de HTML e templates para compor a visualização dos dados 
para o usuário final: 


<ul> 
<li *ngFor="let item of items"> 


<span>{{item.id}} - {{item.name}}</span> 
</li> 
</ul> 





AngularJS utiliza TypeScript, uma linguagem que permite escrever 
código com tipagem próxima a estática e que depois é convertido 
(transpilado) para JavaScript. Esse modelo simplifica o 
desenvolvimento e torna o código mais robusto, mas, para utilizar 
esse framework, é necessário conhecer ambas as linguagens, além 
de HTML e CSS. 


10.6 Repositórios binários 


O Azure Blob Storage é uma solução para armazenamento de 
objetos na nuvem e é otimizado para armazenar grandes 
quantidades de dados não estruturados, ou seja, dados que não 
possuem um modelo definido. 


De acordo com a documentação, o Azure Blob Storage é 
desenhado para os seguintes cenários: 


e Servir imagens e documentos diretamente para o browser. 

e Armazenar arquivos para acesso distribuído. 

e Streaming de áudio e vídeo. 

e Escrita de arquivos de log. 

e Armazenamento de dados de backup e restore, recuperação de 
desastres e arquivamento. 

e Armazenar dados para análise por serviços on-premises ou na 
nuvem. 


Objetos armazenados no Azure Blob Storage sao acessiveis através 
de HTTP/HTTPS de qualquer parte do mundo. Objetos podem ser 
acessados e administrados através da API REST do Azure Storage, 
Azure PowerShell, Azure CLI ou integrado a aplicações através da 
biblioteca cliente disponivel para .NET, JAVA, Node.js, Python, Go, 
PHP e Ruby. 


Armazenamento de imagens em Blob Storage 


No eShopOnWeb, podemos utilizar o Azure Blob Storage como 
repositório para as imagens do catálogo de produtos do site. 


Na atual implementação, as imagens do catálogo são armazenadas 
diretamente no servidor de aplicações em uma subpasta do 
conteúdo estático da aplicação (wwwroot/images/products). No 
capítulo 1, usamos o Azure Files para criar um mapeamento 
externo dessa pasta para arquivos armazenados na nuvem. Essa é 
uma solução rápida para o cenário de Lift & Shift onde o objetivo é 
mover a aplicação para a nuvem com o mínimo de alterações 
possível. 


Com essa estrutura de pasta compartilhada, todo o acesso a 
conteúdo estático passa obrigatoriamente pela aplicação para ser 
servido para o browser, o que aumenta a carga de trabalho nas 
nossas instâncias de aplicação. 


ro 
a 
App Service Azure Files 
Usuário (Web) 





Figura 10.7: Imagens acessadas através da aplicação. 


Considerando que as imagens de catálogo não contêm nenhum 
conteúdo dinâmico e nenhuma informação confidencial que exija 


controles de acesso, elas podem ser servidas diretamente a partir 
do storage com ganhos de escalabilidade para a solução. 


e App Service Storage blob 
Usuario (Web) 





Figura 10.8: Imagens obtidas diretamente do storage. 


O código que salva as imagens está na aplicação Web na classe 
FileController € é executado pelo código na API pública da 
aplicação no momento em que um item do catálogo é criado ou tem 
a sua imagem alterada. 


As imagens são recebidas em formato Basee4 , convertidas 
novamente para binário e salvas usando as classes de manipulação 
de arquivos presentes no namespace system.Io. 





[Route("[controller]")] 
[ApiController] 
public class FileController : ControllerBase 


{ 


[HttpPost] 
[AllowAnonymous ] 
public IActionResult Upload(FileViewModel fileViewModel) 


if (!Request.Headers.ContainsKey("auth-key") || 
Request.Headers["“auth-key"].ToString() != 
ApplicationCore.Constants 
- AuthorizationConstants 
.AUTH KEY) 


return Unauthorized(); 


if(fileViewModel == null || 
string. IsNullOrEmpty(fileViewModel.DataBase64)) 
return BadRequest(); 


var fileData = Convert. FromBase64String( 
fileViewModel.DataBase64); 


if (fileData.Length <= 0) 
return BadRequest(); 


var fullPath = Path.Combine( 
Directory.GetCurrentDirectory(), 
@"wwwroot/images/products", 
fileViewModel.FileName) ; 


if (System.1I0.File.Exists(fullPath) ) 


{ 
System.1I0.File.Delete(fullPath) ; 


System. IO.File.writeAllBytes(fullPath, fileData) ; 


return Ok(); 





Alterar o repositorio para o Azure Blob Storage 


Para utilizar o Blob Storage, é necessário criar um Storage Account 
no Azure. Esse passo pode ser feito pelo portal ou via linha de 
comando com o Azure CLI. 


Vamos usar o Azure CLI no PowerShell para criar um Resource 
Group e Storage Account: 


az group create 
-g rg-eshoponweb 
-l brazilsouth 
az storage account create 
-n steshopdata 
-g rg-eshoponweb 
-1 brazilsouth 





Resource Groups no Azure são uma forma de agrupar recursos 
relacionados. No exemplo a seguir, foi criado um grupo de recursos 
( rg-eshoponweb ) e, dentro dele, uma conta de armazenamento. 


az storage container create 
--account-name steshopdata 


-n catalogimages 
--public-access blob 





Definimos um contêiner para armazenar as imagens dos produtos. 
Um contêiner contém um conjunto de blobs e pode ser comparado a 


uma pasta no sistema de arquivos, enquanto os blobs sao o 
equivalente a arquivos. 


No Visual Studio, podemos utilizar o Cloud Explorer para navegar 
pelos recursos do Azure. Na imagem a seguir, podemos ver a janela 
do Cloud Explorer exibindo a conta de armazenamento e o contéiner 
Criados nos passos anteriores: 


Cloud Explorer Ilx 


Resource Groups w Q, 


esources x pe, 


Collapse All Refresh All 
4 (6) rg-eshoponweb 

b master 
b MicrosofteShopOnWeb.CatalogDb 
b MicrosofteShopOnWeb. Identity 
Ẹ nsg-weballow-ch-001 
@ shutdown-computevm-vm-admin-ch-001 
E sql-eshoponweb-ch-001 

b  stdeploych001 

4 EZ steshopdata 
4 ES Blob Containers 


A 


Ej catalogimages 
> TU Queues 
> E Tables 
vm-admin-ch-001 
[=] vm-admin-ch-001-ip 


Figura 10.9: Blob Containers no Visual Studio Cloud Explorer. 


O contéiner catalogimages será usado pela nossa aplicação para 
armazenar as imagens do catálogo de produtos em vez da pasta 
compartilhada usada atualmente, e cada arquivo será um blob 
dentro dele. Teremos que alterar o código que faz o upload dos 
arquivos no projeto publicapi para enviar os arquivos diretamente 
para o contêiner criado. 


Vamos retornar ao código. O primeiro passo é acrescentar o pacote 
Nuget Azure.Storage.Blobs dO projeto Infrastructure . 





t b x 
Browse Installed Updates [9 NuGet Package Manager: Infrastructure 
Azure.Storage.Blobs x, G [| Include prerelease Package source: nugetorg ~ GO 
HH Azure.Storage.Blobs @ > nugetorg 
pu Azure.Storage.Blobs © by Microsoft, 4,28M downloads v12.6.0 


This client library enables working with the Microsoft Azure Storage Blob service 
for storing binary and text data. Version: Latest stable 12.6.0 E Install 


hes) Microsoft.Azure.WebJobs.Core © by Microsoft, 47,6M downloads v3.0.22 


¥ + © Options 
This library simplifies the task of adding background processing to your z 
Microsoft Azure Web Sites. The SDK uses Microsoft Azure Storage, triggering a... 
Ba Description 
WindowsAzure.Storage & by Microsoft, 107M downloads v9.3.3 
| ge A EE This client library enables working with the Microsoft Azure Storage Blob service for 
A client library for working with Microsoft Azure storage services including blobs, storing binary and text data. 
files, tables, and queues. For this release see notes - https://github.com/Azure/azure-sdk-for-net/blob/master/ 


sdk/storage/Azure.Storage.Blobs/README.md and hitps://github.com/Azure/azure-sdk- 
b Azure.Storage.Blobs.Batch © by Microsoft, 71K downloads v2.3.1 for-net/blob/master/sdk/storage/Azure.Storage.Blobs/CHANGELOG.md 
This client library allows you to batch multiple Azure Blob Storage operations in in addition to the breaking changes https://github.com/Azure/azure-sdk-for-net/blob/ 


a single request. master/sdk/storage/Azure.Storage.Blobs/BreakingChanges.txt 


v Microsoft Azure Storage quickstarts and tutorials - https://docs.microsoft.com/en-us/ 
azure/storage/ 
Each package is licensed to you by its owner. NuGet is not responsible for, nor does it grant any licenses Microsoft Azure Storage REST API Reference - https://docs.microsoft.com/en-us/rest/ 
to, third-party packages. api/storageservices/ 
f REST API Reference for Blob Service - https://docs.microsoft.com/en-us/rest/api/ 
a Do not show this again storageservices/blob-service-rest-api 


Figura 10.10: NuGet Package Manager 


Esse projeto define uma classe chamada webFilesystem, que recebe 
os bytes do arquivo e faz a cnamada para O Filecontroller no 
projeto Web. Como o nosso objetivo é enviar as imagens para o 
Azure Blob Storage, vamos cortar o passo de enviar o arquivo para 
a aplicação Web, enviando o arquivo diretamente para o contêiner. 


Na classe webFilesystem, vamos alterar o código do método 
UploadToweb para enviar os arquivos para o blob storage. O código 
atual pode ser visto a seguir: 


public class WebFileSystem: IFileSystem{ 


private async Task<bool> UploadToWeb( 
string fileName, byte[] fileData) 


var request = new FileItem 

{ 
DataBase64 = Convert. ToBase64String(fileData), 
FileName = fileName 

> 

var content = new StringContent( 
JsonSerializer.Serialize(request), 
Encoding.UTF8, "application/json"); 


using var message = await 
“httpClient.PostAsync( url, content); 


if (Imessage.IsSuccessStatusCode) 


{ 


return false; 


return true; 





E este é o código alterado para fazer o upload para o blob storage: 





using Microsoft.Extensions.Options; 
using Microsoft.eShopWeb. Infrastructure. Data. Gorte: 


namespace Microsoft.eShopWeb. Infrastructure.Services 


{ 
public class WebFileSystem: IFileSystem 


private readonly StorageConfiguration _options; 


public WebFileSystem( 
IOptions<StorageConfiguration> options) 


_options = options.Value; 


} 


private async Task<bool> UploadToWeb( 
string fileName, byte[] fileData) 


BlobServiceClient blobServiceClient = 
new BlobServiceClient(_options.ConnectionString); 
BlobContainerClient containerClient = 
blobServiceClient.GetBlobContainerClient( 
_options.Container); 


BlobClient blobClient = containerClient 
.GetBlobClient(fileName); 


MemoryStream stream = new MemoryStream(fileData); 


await blobClient.UploadAsync(stream, 
new BlobUploadOptions { 
HttpHeaders = new BlobHttpHeaders { 
ContentType=$"image/ 
{Path.GetExtension(fileName).Substring(1)}" 


}); 


return true; 





Note que, no código, nao é mais feita a conversão dos bytes da 
imagem para o formato Base64 uma vez que o SDK faz o envio dos 
dados em formato binário. 


A classe storageConfiguration representa as configurações do blob 
storage no arquivo de configurações do projeto PpublicaPI 
( appsettings.json ). AS configurações de acesso são: 


>, 
"Storage": { 
"ConnectionString": "<connectionString do blob storage>", 


"Container": "catalogimages" 


} 





A string de conexão do storage é obtida no portal do Azure através 
da opção Chaves de Acesso. Copie a primeira string de conexão. 


Microsoft Azure (Versão prévia) Æ Pesquisar recursos, serviços e documentos (G+/) 





Página inicial > steshopdata 








? steshopdata | Chaves de acesso & x 
o Conta de armazenamento O Diretório: Microsoft 
Sk ZI Pesquisar (Ctrl+/) | « Use as chaves de acesso para autenticar seus aplicativos ao fazer solicitações à conta de 
Armazenamento do Azure. Armazene suas chaves de acesso com segurança usando o Azure Key 
= Visão geral Vault, por exemplo, e não as compartilhe. E recomendado regenerar as chaves regularmente. Você 
n = E recebe duas chaves para que seja possível manter as conexões usando uma chave enquanto a outra 
E Log de atividade é regenerada. 
ra 
we Marcações É du 
há ç Ao regenerar suas chaves de acesso, atualize todos os recursos e aplicativos do Azure que acessam 
4? Diagnosticar e resolver proble... essa conta de armazenamento para usar as novas chaves. Essa ação não interromperá o acesso aos 
discos de suas máquinas virtuais. 
O Ro IAM (Controle de Acesso) Saiba mais sobre como regenerar chaves de acesso de armazenamento C? 
a = a é 
KE Transferência de dados Nome da conta de armazenamento 
$ Eventos steshopdata D 





E a 
- = Gerenciador de Armazename... Ocultar as chaves 








e Configurações key1 Č) 
® Chaves de acesso Chave 
a O Replicação G e | ntwilDN6AIMAOgh+XA23vM2G9gwPcOBgX7tQZ4n/ta0BbyycRrNHROTqAO6dMjDr7rUBV6s/5... a | 
eplicação Geográfica —— br rr rr rr rr rk — rr rr rn 
& CORS Cadeia de conexão 
< | DefaultEndpointsProtocol=https;AccountName=steshopdata;AccountKey=ntwilIDN6AIMAQg... D | 
tm Configuração 
Ea 
GO Criptografia key2 Č) 


Chave 


Cas Accinatiura da aracen camnart 


Figura 10.11: Obter a string de conexao no Portal do Azure 


Após acrescentar as novas configurações ao arquivo, o próximo 
passo é alterar a configuração de injeção de dependências para 
injetar uma instância de Ioptions<StorageConfiguration> no construtor 
da classe webFileSystem , que alteramos. 


Procure pelo código: 


services. AddScoped<IFileSystem, WebFileSystem>( 


x => new WebFileSystem($"{baseUrlConfig.WebBase}File")); 





E altere para o código a seguir: 


services.Configure<StorageConfiguration>( 
Configuration.GetSection( 


StorageConfiguration.StorageConfigSection)); 
services.AddScoped<IFileSystem, WebFileSystem>(); 





As nossas imagens agora serão armazenadas no blob storage e 
serão servidas diretamente para o browser, portanto é necessário 
configurar a URL base das imagens no arquivo appsettings.json : 


"CatalogBaseUrl": "https://<nome da storage account> 


.blob.core.windows.net", 





Com essas alterações, movemos as imagens da pasta da aplicação 
para um armazenamento externo, escalavel e capaz de armazenar 
grandes volumes de dados. 


Também tiramos da aplicação Web o papel de servir as imagens da 
aplicação. Pode parecer um custo pequeno, porém, em cenários de 
alto volume, esse fôlego adicional pode evitar o aumento do número 
de instâncias dos serviços em execução com economia que pode 
ser medida de forma objetiva na conta mensal de consumo. 


10.7 Resumo 


Neste capítulo, conseguimos abordar práticas de programação que 
promovem o baixo acoplamento no código: 


e Vimos como as interfaces ajudam a tornar as dependências 
mais flexíveis e como a injeção de dependências ajuda a obter 


um codigo mais flexivel, limpo, organizado e testavel. 

e Também foi possível ver como criar e disponibilizar APIs Web, e 
como acessar APIs a partir de clientes remotos. 

e Vimos como foi possível alterar o repositório de imagens do 
catálogo com poucas alterações de código e sem criar impactos 
na aplicação. 


CAPITULO 11 
Microsserviços 


Escrito por lury Oliveira. 


CENÁRIO 


Como podemos evoluir nossa aplicação para que ela possa 
atender a uma maior demanda de usuários? Como adequar a 
aplicação para atender aos acordos de nível de serviço e 
garantir uma boa relação de custo/benefício? Como reduzir o 
caos e o estresse? 


Neste capítulo, vamos: 


e Modernizar nossa aplicação exemplificando um modelo de 
microsserviços. 

e Centralizar as configurações dos serviços em um único 
lugar. 

e Migrar a versão do NEI para a versão 5. 





Analisar e gerenciar o ciclo de vida de uma aplicação devem ser 
atividades constantes para as empresas, mas que por vezes são 
negligenciadas por diversas razões: ora por falta de conhecimento 
do assunto, ora pela simples expectativa de que a aplicação morrerá 
em breve. 


A falta de clareza sobre o ciclo de vida das aplicações faz com que 
muito esforço de diferentes times seja investido para manter a 
operação. Sem contar o pesadelo de publicar uma nova versão ou 
mesmo, em um momento de crise, a dificuldade de entender a 
causa raiz de um problema. Tudo isso pode levar a momentos de 
estresse e perdas financeiras para a organização. 


Diversas possibilidades emergem para evoluir uma aplicação ou 
mesmo criar uma nova que a substitua. Uma estratégia muito 
difundida é o uso de microsserviços, que ganhou grande 
popularidade com as histórias de empresas, como Netflix, Spotify e 
LinkedIn, que adotaram arquiteturas baseadas nessa estratégia. 


A receita de sucesso dessas empresas não será a garantia de 
nosso sucesso ao adotarmos microsserviços como padrão para 
nossas aplicações, por isso devemos considerar os benefícios e as 
desvantagens sobre tal padrão arquitetural. Afinal, nenhuma 
arquitetura é bala de prata, não é? 


11.1 Vantagens ao adotar microsserviços 


Primordialmente devemos ter um entendimento inicial do conceito 
de microsserviços. Martin Fowler e James Lewis (2014), definem 
como sendo: 


[...] um estilo de arquitetura de microsserviço é uma abordagem 
para desenvolver um único aplicativo como um conjunto de 
pequenos serviços, cada um executando em seu próprio processo e 
se comunicando com mecanismos leves, geralmente utilizado em 
APIs com o protocolo HTTP. Esses serviços são desenvolvidos em 
torno de recursos de negócios e podem ser implantados de forma 
independente por meio de processos de implantação totalmente 
automatizados. Há um mínimo de gerenciamento centralizado 
desses serviços, que podem ser escritos em diferentes linguagens 
de programação e usar diferentes tecnologias de armazenamento 
de dados. (tradução livre) 


Outra definição criada por Sam Newman (2019, v. 2, p. 1) descreve 
microsserviços como '[...] serviços independentes modelados ao 
redor de um domínio de negócios." (tradução livre) 


Diversas definições podem ser encontradas na internet, mas por ora 
podemos simplificar a definição de microsserviços como sendo 
pequenas unidades de código, executadas dentro de seu próprio 
processo, mantendo-se independentes e se comunicando com 
outros processos através de protocolos, como HTTP/HTTPS, AMQP 
ou WebSockets. 


Com essas definições em mente, passamos a explorar os benefícios 
que uma arquitetura utilizando microsserviços pode nos trazer. 


Diminuição do acoplamento 


Pensemos em um projeto que envolva diversos times, como 
podemos ver a seguir. 
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Figura 11.1: Multiplos times trabalhando em um mesmo release. 


Todos compartilham dependéncias. Quando ha problemas ou bugs 
com algum ou alguns times, os outros serao afetados. Reduzindo 
essa interdependéncia, ganhamos em aspectos, como: 


e Facilidade e agilidade na publicação; 
e Escalabilidade e disponibilidade de forma segregada; 
e Isolamento de problemas. 


Figura 11.2: Único caminho de produção do código 


Como cada serviço possui seu próprio ciclo de vida, novas 
publicações podem ocorrer sem que haja impacto no ciclo de vida 
das demais e com isso conseguimos mitigar possíveis problemas. 


Microsserviços e DevOps 


A adoção de microsserviços pode aumentar a velocidade do time, e 
as práticas de DevOps reforçam a ideia de quebrar grandes 
problemas em partes menores e enfrentá-los um de cada vez como 
uma equipe se encaixando perfeitamente nos ideais de Devops. 


Existem diversas pesquisas com o intuito de entender como as 
empresas estão utilizando e adotando DevOps em seu dia a dia. 
Uma delas é denominada DevOps Pulse, que analisa dados 
submetidos por profissionais de diversos perfis, como engenheiros 
de software, de plataforma, de site reliability e de DevOps, e os 
disponibiliza ano a ano. Outra pesquisa importante, conduzida por 
um consórcio de empresas formado por Puppet, Circle Cl Services 
Now, dentre outras, gera também anualmente um relatório 
denominado State of Devops. 


Esses relatórios trazem diversos indicadores, como lead time, 
frequência de publicação de nova versão, tempo médio de 


recuperação e percentual de falhas em novas publicações como 
sendo parte dos requisitos de avaliação de maturidade das 
organizações e objetivos a serem buscados. Essas métricas e 
técnicas vão além do escopo do livro, mas recomendamos que você 
se aprofunde um pouco mais e tente tirar proveito delas! 


Os indicadores apresentados nesses relatórios são relevantes para 
o contexto de DevOps e microsserviços, como, por exemplo, a 
frequência com que uma organização realiza deployment ou publica 
uma nova versão de software relacionando-o a um período de 
tempo, que pode ser medido em dias, semanas ou meses. Para que 
possamos incrementar o numero de deployments realizados por dia, 
por exemplo, devemos ter em mente duas práticas: continuous 
integration (Cl) e continuous delivery (CD), onde esta consiste em 
reduzir os ciclos de desenvolvimento, entregando softwares 
confiáveis prontos para serem publicados e aquela, na integração 
constante das alterações de código na branch principal de um 
repositório, testando as alterações o mais cedo e com a maior 
frequência possível. 


Neste momento, cabe uma reflexão: Quais as facilidades e 
melhorias que os microsserviços podem trazer para os indicadores 
de devops, como, por exemplo, frequência de publicação de nova 
versão? 
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Figura 11.3: Com que frequência sua equipe implanta código na produção (back-end, front- 
end etc.) ? 
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Figura 11.4: Você tem uma estratégia de Integração Contínua (Cl) em vigor? 
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Figura 11.5: Vocé tem uma estratégia de entrega continua em vigor? 


A mesma pesquisa também nos mostra como a adoção de 
microsserviços está aumentando pelas empresas se compararmos 
os anos de 2016 e 2019, por exemplo. 
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Figura 11.7: Adoção de Microsserviços em 2019 


11.2 Microsserviços: usar ou não usar? 


80 


Com grandes poderes vém grandes responsabilidades!. Essa 
famosa frase popularizada pelo filme O Homem Aranha da Marvel 
chama nossa atenção para alguns pontos que devemos considerar 
quando adotamos uma arquitetura de microsserviços. 


O primeiro aspecto trata da complexidade de orquestração: muitos 
serviços devem ser mantidos em diversos ambientes, com 
monitoração constante, resiliência, aspectos relacionados à 
segurança, entre outros. 


Outro aspecto importante que muitas empresas não levam em 
consideração é o grande consumo de recursos de rede, dada a 
quantidade de serviços que se comunicam utilizando protocolos de 
rede diversos, o que gera grande tráfego dentro da infraestrutura. 


Vale citar que, ao adotar microsserviços, cada qual tende a ter seu 
próprio repositório para armazenamento de dados. Então eles 
podem estar espalhados, o que traz complexidade no que diz 
respeito à integridade e à consistência. 


Monitoramento e rastreabilidade (logging) de operações se tornam 
complexos e necessários para entendermos sobre a saúde dos 
serviços e identificarmos problemas. Muitas vezes serão 
necessárias informações de múltiplas fontes para análise, 
especialmente se tivermos diversos serviços envolvidos na 
realização de uma operação. 


Para aumentar a confiabilidade dos microsserviços e aplicações, 
são necessários testes usando diferentes estratégias e um 
consistente formato na utilização de roteamento e service discovery, 
que possibilita a detecção automática de serviços publicados dentro 
de uma infraestrutura, como um serviço de balanceador de carga, 
por exemplo. 


Para a nossa aplicação, como seriam as mudanças? Dados os 
desafios mostrados, vale a pena? 


Vamos explorar um pouco mais a ideia de termos uma aplicagao no 
formato monolítico e se, de fato, migrar essa aplicação para uma 
arquitetura baseada em microsserviços seria algo que traria valor 
para o contexto de nossa aplicação. 


No capítulo 1, nos deparamos com uma aplicação criada como 
sendo um bloco único conhecido como monólito, o que por anos foi 
um padrão de desenvolvimento de aplicações largamente 
empregado e replicado por diversas empresas. Mark Russinovich, 
em seu artigo Microservices: An application revolution powered by 
the cloud, ressalta que esse tipo de arquitetura de aplicação é o 
resultado de fatores, como o custo, tempo e complexidade para o 
provisionamento de infraestrutura para hospedar as aplicações. 


Um monolito é normalmente uma aplicação onde todos os módulos 
são empacotados juntos em uma única unidade de execução. Por 
exemplo, pode ser um Java Web Application (WAR) em execução 
no Tomcat ou um aplicativo ASP.NET executado no IIS. Um 
aplicativo monolítico típico usa um design em camadas separadas 
para a interface de usuário (UI), lógica de aplicativo e acesso a 
dados. 
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Figura 11.8: Aplicativo em 3 camadas 


Esses sistemas, em muitos casos, começam pequenos, mas 
tendem a crescer com o tempo para suportar as necessidades do 
negócio da empresa. Porém, em algum ponto, conforme novos 
recursos são adicionados, o aplicativo monolítico pode começar a 
sofrer dos seguintes problemas: 


e As partes individuais do sistema não podem ser dimensionadas 
independentemente, porque estao fortemente acopladas. 

e É difícil manter o código devido ao acoplamento rígido e às 
dependências ocultas. 

e O teste fica mais difícil, aumentando a probabilidade de 
introdução de vulnerabilidades. 


Esses problemas podem se tornar obstáculos para o crescimento e 
estabilidade da aplicação. As equipes ficam cautelosas ao fazer 
alterações, especialmente se os desenvolvedores originais não 
estiverem mais trabalhando no projeto e os documentos de design 
forem esparsos ou desatualizados. 


Apesar dessas limitações, um design monolítico pode fazer sentido 
como ponto de partida para um aplicativo. Os monólitos costumam 
ser o caminho mais rápido para construir uma prova de conceito ou 
um produto mínimo viável. Nas fases iniciais de desenvolvimento, os 
monólitos tendem a ser: 


e Mais fácil de construir, porque há uma única base de código 
compartilhada entre os desenvolvedores. 

e Mais fácil de depurar, porque o código é executado em um 
Único processo e espaço de memoria. 

e Mais fácil de raciocinar, porque há menos componentes a 
considerar. 


Conforme o sistema cresce em complexidade, essas vantagens 
podem acabar desaparecendo. Monólitos grandes geralmente se 
tornam cada vez mais difíceis de modificar e depurar. Com o tempo, 
os problemas podem superar os benefícios. 


Este é o ponto em que pode fazer sentido migrar o aplicativo para 
uma arquitetura de microsserviços. Ao contrário dos monólitos, os 
microsserviços são unidades de execução normalmente 
descentralizadas e de baixo acoplamento. 


Migrar um monólito para uma arquitetura em microsserviços pode 
tomar um tempo considerável e investimento significativo para evitar 


falhas ou saturações. Para garantir que qualquer migração seja 
bem-sucedida, é bom entender os benefícios e os desafios que os 
microsserviços trazem. 


Retomando a aplicação apresentada no capítulo 1 e que está em 
um processo de modernização no decorrer deste livro, observamos 
que ainda há acoplamento, uma vez que não podemos segregar 
diversos módulos ou partes específicas da aplicação em outros 
serviços de modo independente. 
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Figura 11.9: Projeto Web e suas dependéncias 


Como podemos verificar analisando as dependéncias do projeto 
Web, ele é associado a mais quatro projetos que, além da 
dependência entre os componentes, possui diversos assuntos 
distintos, os quais chamaremos de dominios de negócio. Temos, por 
exemplo, os seguintes domínios de negócio dentro da mesma 
aplicação: Catalog, Basket e Order. 


Eis que surge o questionamento: todos os domínios de negócio 
dentro da mesma aplicação é um problema”? Talvez não! 


Vamos analisar o cenário de negócio no qual temos um aumento no 
número de pedidos desse e-commerce. Como podemos escalar a 
aplicação para se adequar a ele? Com um monólito, se escalarmos 
a aplicação, todos os domínios de negócio serão escalados, mas é 
isso mesmo o que queremos? Faz sentido aumentar as áreas da 
aplicação que não necessitam desse requisito de negócio? 


Podemos publicar toda a aplicação em diversos servidores, criando 
diversas instâncias, usando balanceadores de carga e, todas as 
vezes em que precisarmos de mais recursos para o banco de 
dados, aumentamos o tamanho do servidor. De novo, isso é um 
problema? Se fizermos uma análise sob uma perspectiva de 
agilidade, facilidade de manutenção e outros aspectos, podemos 
considerar que temos um problema. 


Dessa forma, vamos exemplificar a quebra da funcionalidade de 
pedidos (Order) dessa aplicação. A ideia é criarmos um 
microsserviço independente e totalmente responsável para 
retornar/manipular os dados relacionados aos pedidos e somente 
pedidos. 





Solution Explorer 


OE osaB nr See E 

Search Solution Explorer (Ctrl+ç) 

af] Solution 'eShopOnWeb' (T of 7 projects) 

b DO Solution Items 

d ua) SIC 
> ake] ApplicationCore 
b am] BlazorAdmin 
b elei BlazorShared 
> alee] Infrastructure 
b am] OrderApi 
b am] PublicApi 
b alm] Web 


Figura 11.10: Inserção do novo projeto OrderApi. 


O modo mais simples é removermos o código e expô-lo como uma 
Web API. Iniciaremos isolando o processo responsável por 
hospedar a funcionalidade Order e, para isso, criamos um novo 
projeto denominado OrderApi. 


Como um dos princípios de modelagem de microsserviços, no qual 
cada microsserviço deverá implementar um domínio de negócio 
específico atuando de forma autônoma com relação a outras partes 
da aplicação, no qual possamos escalar, publicar e alterar, sem que 
impactemos outros microserviços e/ou domínios da aplicação, 
temos: 
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Figura 11.11: Decomposição do projeto Web 


O projeto OrderApi ficará da seguinte forma: 
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Figura 11.12: Exemplo do projeto OrderApi 


Para chegarmos a esse nivel de isolamento do dominio de negocio 
Order, criamos o projeto da imagem. Esse novo projeto é uma Web 
API escrita em MVC utilizando .NET 5, lembrando que poderiamos 

usar qualquer linguagem de programação e framework com suporte 
a APIs REST. 


Na versão anterior, tinhamos o código a seguir para tratar Order. 
Havia uma classe do tipo controller que implementava o Pattern 
Mediator através da biblioteca mediatr e era responsável por todas 
as requisições do domínio de negócio Order. 


using 
using 
using 
using 
using 
using 
using 





MediatR; 

Microsoft.AspNetCore. Authentication. Cookies; 
Microsoft.AspNetCore. Authorization; 
Microsoft.AspNetCore.Mvc; 
Microsoft.eShopWeb.Web.Features.MyOrders; 
Microsoft.eShopWeb.Web.Features.OrderDetails; 
System. Threading. Tasks; 


namespace Microsoft.eShopWeb.Web.Controllers 


{ 


[ApiExplorerSettings(IgnoreApi = true)] 
[Authorize] 
[Route("[controller]/[action]")] 

public class OrderController : Controller 


{ 


private readonly IMediator _mediator; 


public OrderController(IMediator mediator) 
{ 


_mediator = mediator; 


[HttpGet] 
public async Task<IActionResult> MyOrders() 
{ 


var viewModel = await _mediator.Send( 
new GetMyOrders (User. Identity.Name)); 


return View(viewModel); 


[HttpGet ("{orderId}") ] 
public async Task<IActionResult> Detail(int orderId) 


{ 


var viewModel = await _mediator.Send( 
new GetOrderDetails( 
User. Identity.Name, orderId)); 


if (viewModel == null) 


return BadRequest( 


"No such order found for this user."); 


return View(viewModel); 





Dentro do projeto Web, tínhamos implementações para retornar as 
informações de Order e OrderDetails nas classes GetmyordersHandler 
€ GetMyOrdersDetailsHandler COMO podemos ver no exemplo a seguir: 





using MediatR; 

using Microsoft.eShopWeb.ApplicationCore. Interfaces; 
using Microsoft.eShopWeb.ApplicationCore. Specifications; 
using Microsoft.eShopWeb.Web.ViewModels; 

using System.Collections.Generic; 

using System.Ling; 

using System. Threading; 

using System. Threading. Tasks; 


namespace Microsoft.eShopWeb.Web.Features.MyOrders 
{ 

public class GetMyOrdersHandler : IRequestHandler<GetMyOrders, 
IEnumerable<OrderViewModel>> 


{ 


private readonly IOrderRepository _orderRepository; 


public GetMyOrdersHandler(IOrderRepository orderRepository) 
{ 


_orderRepository = orderRepository; 


public async Task<IEnumerable<OrderViewModel>> Handle( 
GetMyOrders request, 
CancellationToken cancellationToken) 


var specification = new 
CustomerOrdersWithItemsSpecification(request.UserName); 

var orders = await 
_orderRepository.ListAsync(specification); 


return orders.Select(o => new OrderViewModel 
{ 
OrderDate = o.OrderDate, 
OrderItems = o.OrderItems?.Select( 
oi => new OrderItemViewModel() 


PictureUrl = oi.ItemOrdered.PictureUri, 
ProductId = oi.ItemOrdered.CatalogItemId, 
ProductName = oi.ItemOrdered.ProductName, 


UnitPrice = oi.UnitPrice, 
Units = oi.Units 
}).ToList(), 
OrderNumber = o.Id, 
ShippingAddress = o.ShipToAddress, 
Total = o.Total() 
HE 





A implementação para obter as informações a respeito de Orders foi 
movida para o microsserviço denominado OrderApi e teve seu 
controller alterado para não mais usar os artefatos de dentro do 


Projeto Web e, sim, fazer uma requisição via API REST ao novo 
microsserviço. 
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Figura 11.13: Parte do projeto Web que contempla o domínio de pedidos 


Esta é a nova versão do arquivo ordercontroller.cs do Projeto Web, 
que faz referência ao microsserviço de Order usando bibliotecas, 


como o HitpClient para se comunicar com a OrderApi. 


using 
using 
using 
using 
using 
using 
using 
using 
using 





Microsoft.AspNetCore. Authorization; 
Microsoft.AspNetCore.Mvc; 
Microsoft.eShopWeb.ApplicationCore. Entities .OrderAggregate; 
Microsoft.eShopWeb.Web.ViewModels; 

Newtonsoft.Json; 

System.Collections.Generic; 

System.Ling; 

System.Net.Http; 

System. Threading. Tasks; 


namespace Microsoft.eShopWeb.Web.Controllers 


{ 


[ApiExplorerSettings(IgnoreApi = true)] 
[Authorize] 
[Route("[controller]/[action]")] 

public class OrderController : Controller 


{ 


private readonly IHttpClientFactory _clientFactory; 


public OrderController(IHttpClientFactory clientFactory) 
{ 


_clientFactory = clientFactory; 


[HttpGet] 
public async Task<IActionResult> MyOrders() 
{ 


var client = _clientFactory 
.CreateClient("order-api"); 


var response = await client.GetAsync( 
$"/Order/GetByBuyerId/{User.Identity.Name}") 
.ConfigureAwait(false); 


var jsonString = await response.Content 
.ReadAsStringAsync() 
.ConfigureAwait(false); 


var orders = JsonConvert 


.DeserializeObject<IReadOnlyList<Order>>(jsonString) ; 


var viewModel = orders.Select(o => new OrderViewModel 


{ 
OrderDate = o.OrderDate, 
OrderItems = o.OrderItems?.Select(oi => new 
OrderItemViewModel() 
{ 
PictureUrl = oi.ItemOrdered.PictureUri, 
ProductId = oi.ItemOrdered.CatalogItemId, 
ProductName = oi.ItemOrdered.ProductName, 
UnitPrice = oi.UnitPrice, 
Units = oi.Units 
}).ToList(), 
OrderNumber = o.Id, 
ShippingAddress = o.ShipToAddress, 
Total = o.Total() 
HE 


return View(viewModel); 


[HttpGet ("{orderId}") ] 
public async Task<IActionResult> Detail(int orderId) 


{ 


var client = _clientFactory 
.CreateClient("order-api"); 


var response = await client 
.GetAsync($"/Order/{orderId}") 
.ConfigureAwait (false) ; 


var jsonString = await response.Content 
.ReadAsStringAsync() 
.ConfigureAwait (false) ; 


var order = JsonConvert 
.DeserializeObject<Order>(jsonString) ; 


if (!order.BuyerId.Equals(User.Identity.Name) ) 
{ 


return BadRequest("No such order found for this 


user."); 
} 
var viewModel = new OrderViewModel 
{ 
OrderDate = order.OrderDate, 
OrderItems = order.OrderItems.Select( 
oi => new OrderItemViewModel 
{ 
PictureUrl = oi.ItemOrdered.PictureUri, 
ProductId = oi.ItemOrdered.CatalogItemId, 
ProductName = oi.ItemOrdered.ProductName, 
UnitPrice = oi.UnitPrice, 
Units = oi.Units 
}).ToList(), 
OrderNumber = order.Id, 
ShippingAddress = order.ShipToAddress, 
Total = order.Total() 
> 
return View(viewModel); 
} 
} 
} 





Outro arquivo que deve ser alterado é o de configuração, no qual 
referenciamos o endereço base da API. 


"baseUrls": | 
“apiBase": “https://localhost:5099/api/", 
“webBase”: "https://localhost:5001/", 
“orderBase": “https://localhost:5044/" 

I> 


Figura 11.14: Arquivo de configuragao com referéncia ao caminho da API. 


Para implementações de microsserviços, há quem defenda o 
isolamento total dos dados, onde cada microsserviço terá sua fonte 
de dados própria, autônoma e independente. Dessa forma, geramos 
um novo banco de dados desacoplado do banco de dados que 
tínhamos anteriormente e migramos os dados necessários. 





Figura 11.15: Segregação das bases de dados. 


r appsettings.json 


Schema: https://json.schemastore.org/appsettings 


1 af 

2 =: "Logging": { 

3 = "LogLevel": { 

4 | "Default": "Information", 

5 "Microsoft": "Warning", 

6 “Microsoft.Hosting.Lifetime": "Information" 
7 } 

8 +, 

9 =: "ConnectionStrings": { 

10 | “OrderConnection": "Server=tcp:sql-eshoponweb-ch-001.database.windows.ne 
11 3, 

12 “AllowedHosts": "*" 

13 } 


Figura 11.16: Connection String para o banco da API de Order. 


Alterando o processo de CI/CD para compilar o projeto 
OrderApi 


Como fizemos a separação do domínio de pedidos em um projeto 
separado, devemos incluir esse novo projeto nos workflows de 
CI/CD, que atualmente estão no GitHub Action. 


i eshoponweb-ci.yml , i i i i 
No arquivo esh b 1 , precisamos incluir o seguinte trecho 
para a realização da compilação desse novo projeto. 


- name: Build Order API 


run: dotnet build src/OrderApi/OrderApi.csproj 
--configuration Release --no-restore 





Com isso, 0 arquivo eshoponweb-ci.ym1 ficará da seguinte forma. 


name: eshoponweb-ci 


on: 
push: 
branches: [master] 
pull request: 
branches: [master] 


jobs: 
build: 
runs-on: ubuntu-latest 


steps: 
- uses: actions/checkout(dv2 


name: Setup .NET Core 
uses: actions/setup-dotnet@v1 
with: 

dotnet-version: 3.1.301 


name: Install dependencies 
run: dotnet restore 


Build Public API 
: dotnet build src/PublicApi/PublicApi.csproj 
--configuration Release --no-restore 


Build Order API 


: dotnet build src/OrderApi/OrderApi.csproj 
--configuration Release --no-restore 


Build Web 
: dotnet build src/Web/Web.csproj 
--configuration Release --no-restore 


name: Test 
run: dotnet test --no-restore --verbosity normal 





O arquivo que contempla a entrega continua ( eshoponweb-cd.ym1 ) 
sofrerá a mesma alteração na parte inicial. 


Por fim, agora devemos definir onde e como vamos hospedar o 
microsserviço. 


11.3 Onde hospedar nossa aplicação OrderApi? 


Agora que temos uma nova aplicação, devemos escolher onde e 
como devemos hospedá-la. O repositório de Arquitetura de Azure 
traz as diversas possibilidades que temos para hospedar nossas 
aplicações. Para tal, sugerimos ao leitor que visite a página 
https://docs.microsoft.com/en- 
us/azure/architecture/guide/technology-choices/compute-decision- 
tree. 


Para a hospedagem de microsserviços, duas possibilidades são as 
mais comuns nos dias atuais: 


e Um orquestrador de serviço que gerencia serviços em 
execução em nós dedicados (VMs). 

e Uma arquitetura Serverless usando funções como serviço 
(FaaS). 


Orquestradores de serviço 


Um orquestrador lida com tarefas relacionadas à implantação e 
gerenciamento de um conjunto de serviços. Essas tarefas incluem: 
publicar serviços nas máquinas virtuais conhecidas como nós, 
monitorar a integridade e saúde dos serviços, reiniciar se 
necessário, analisar a carga entre os serviços e redistribuir a carga 
quando necessário. Os orquestradores mais populares são 
Kubernetes, Service Fabric, DC/OS e Docker Swarm. 


No Azure, temos as seguintes opções: 


e O Azure Kubernetes Service (AKS) é um serviço Kubernetes 
gerenciado. O AKS provisiona o cluster Kubernetes, hospeda, 
gerencia e expõe os endpoints da API do Kubernetes 
realizando upgrades, patching, escalonamento e outras tarefas 
de gerenciamento de forma automatizada. 

e O Service Fabric é uma plataforma de sistemas distribuídos 
para empacotar, implantar e gerenciar microsserviços. Os 
microsserviços podem ser implantados no Service Fabric, como 
contêineres, executáveis, binários ou Reliable Services. Usando 
o modelo de programação do Reliable Services, os serviços 
podem usar diretamente APIs do Service Fabric para consultar 
o sistema, relatar integridade, receber notificações sobre 
configurações e alterações de código e descobrir outros 
serviços. 

e Outras opções, como Docker Enterprise Edition e Mesosphere 
DC/OS, podem ser executadas em um ambiente laaS no Azure. 


Serverless 


Serverless é um modelo de execução de computação em nuvem 
que provisiona recursos sob demanda e atribui toda a 
responsabilidade por tarefas comuns de gerenciamento de 
infraestrutura (por exemplo, dimensionamento, programação, 
patching, provisionamento etc.) aos fornecedores de nuvem e 
ferramentas, permitindo que os desenvolvedores concentrem seu 
tempo e esforço na lógica de negócios específica para seus 
aplicativos ou processos. 


No Azure, temos Azure Functions, uma solução serverless que 
permite que menos código seja escrito, mantendo menos 
infraestrutura e economizando nos custos. Em vez de nos 
preocuparmos com a implantação e manutenção de servidores, a 
infraestrutura de nuvem fornece todos os recursos atualizados 
necessários para manter as aplicações em execução. 


Orquestrador ou Serverless? 


Aqui estao alguns fatores a serem considerados ao escolher entre 
uma abordagem ou outra: 


Facilidade de gerenciamento: serverless traz a vantagem de total 
gerenciamento de recursos. Embora um orquestrador abstraia 
alguns aspectos do gerenciamento e configuração do cluster, ele 
não oculta completamente as VMs. Com um orquestrador, questões 
como balanceamento de carga, uso de CPU, de memória e de rede 
devem ser gerenciadas. 


Flexibilidade e controle: um orquestrador oferece grande controle 
sobre a configuração e o gerenciamento de seus serviços. Com 
serverless, parte desses detalhes são abstraídos. 


Portabilidade: todos os orquestradores listados aqui (Kubernetes, 
DC OS, Docker Swarm e Service Fabric) podem ser executados on- 
premisses ou em cloud. 


Custo: com um orquestrador, você paga pelos recursos das 
máquinas virtuais que estão sendo executadas no cluster. Com 
serverless, paga-se apenas pelos recursos de computação 
consumidos. Em ambos os casos, deve-se considerar o custo de 
quaisquer serviços adicionais, como armazenamento, bancos de 
dados e serviços de mensageria. 


Escalabilidade: Azure Functions é dimensionado automaticamente 
para atender à demanda com base no número de eventos. Com um 
orquestrador, você pode expandir aumentando o número de 
instâncias de serviço em execução no cluster. 


Para esta solução, adotaremos o uso do Azure Kubernetes Service. 


11.4 Centralizar o armazenamento e o 
gerenciamento de configurações das aplicações 


Como você sabe, as configurações de uma aplicação em ASP.NET 
estão localizadas no arquivo appsettings.json e, como forma de 
centralizar e facilitar a gestão dessas configurações em nossa 
solução, vamos criar dois recursos no Azure. O primeiro será um 
Azure Key Vault, para armazenamento seguro de informações 
sensíveis, e o outro será um App Configuration, onde 
armazenaremos todas as configurações de cada parte da aplicação 
que precisem ser alteradas de ambiente para ambiente. 


Antes de criar os recursos, devemos criar um grupo onde todos os 
recursos que utilizarmos daqui para frente serão organizados. Esse 
recurso do Azure se chama Resource Group e é criado da seguinte 
forma, através do Azure CLI. 


az group create 


--name rg-eshoponweb-cloud 
--location brazilsouth 





Com o grupo de recursos criado, podemos agora criar o Key Vault, 
sendo este um recurso centralizado e seguro para armazenar e 
gerenciar certificados, chaves e outros segredos da aplicação, e o 
App Configuration, que fornece um serviço para gerenciar, também 
de modo central, as configurações do aplicativo e features flags. 


# Key Vault 

az keyvault create 
-g rg-eshoponweb-cloud 
-n keyvault-eshoponweb 
-l brazilsouth 


# App Configuration 


az appconfig create 
-g rg-eshoponweb-cloud 
-n appconfig-eshoponweb 
--sku Standard 
-l brazilsouth 





Após criados, precisamos alterar a aplicação para que seja possível 
conectar-se a esses novos recursos. Para isso, precisamos seguir o 
passo a passo adiante. 


Passo 1 


Adicione os seguintes pacotes Nuget nos projetos Web, PublicApi e 
OrderApi, para que a aplicação possa conectar e consumir os 
recursos recém-criados: 


e Microsoft.Azure.AppConfiguration.AspNetCore 
e Azure.lIdentity 


Passo 2 


No arquivo Program.cs de cada um dos projetos, altere o método 
CreateHostBuilder acrescentando o código para que sua aplicação 
consiga acessar o Azure App Configuration e resgatar as 
informações. Atente-se ao filtro dos itens. Para cada aplicação, 
filtraremos somente as configurações para o projeto em questão. 


public static IHostBuilder CreateHostBuilder(string[] args) => 
Host.CreateDefaultBuilder (args) 
-ConfigureWebHostDefaults (webBuilder => 

webBuilder.ConfigureAppConfiguration(config => 

{ 
var settings = config.Build(); 
config.AddAzureAppConfiguration(options => 

options 


.Connect(Environment.GetEnvironmentVariable("APPCONFIG CONNECTIONSTRIN 


G")) 

.ConfigureKeyVault(kv => 

{ 

kv.SetCredential(new 

DefaultAzureCredential()); 

}) 

.Select(KeyFilter.Any, LabelFilter.Null) 

.Select(KeyFilter.Any, "Web") 

)5 
)) .UseStartup<Startup>()); 





Com a aplicação configurada, precisamos criar um Service Principal 
para acessar recursos protegidos por um Azure AD Tenant, em 
nosso caso, um Azure Key Vault a partir do Azure App 
Configuration. O Service Principal é uma representação local de 
uma instância de um aplicativo criado dentro de um tenant com o 
objetivo de definir o que uma aplicação pode fazer dentro daquele 
tenant, qual tipo de recurso pode acessar, por exemplo. 


# Criar um Service Principal 

az ad sp create-for-rbac 
-n "AzureKeyVault-AKS-eShopOnWeb" 
--sdk-auth 


# Atribuir uma politica de permissionamento do SP com o Key Vault 
az keyvault set-policy 

-n keyvault-eshoponweb 

--spn <client_id> 

--secret-permissions delete get list set 


--key-permissions create decrypt delete encrypt 


get list unwrapKey wrapKey 





Anote os valores do client id, client secret e tenant id, que 
utilizaremos mais para frente na configuração do GitHub Action 
juntamente com a entrega dos artefatos no Azure Kubernetes 
Service. Lembre-se de que o Service Principal gerado contemplará 
um client secret com uma data de expiração. 


Após configurado, adicione as configurações (chaves) das 
aplicações ao recurso do Azure App Configuration, conforme as 
linhas de comando a seguir ou através do portal do Azure. Essas 
configurações determinarão quais recursos sua aplicação deverá 
consumir. 


CatalogConnection: 


# Criação da string de conexão no Key Vault 
az keyvault secret set 
--name CatalogConnection 


--vault-name keyvault-eshoponweb 
--value "Server=tcp:<replaceserver>,1433;..." 


# Criação da configuração da string de conexão referenciando 
# ao item do Key Vault criado anteriormente 
az appconfig kv set-keyvault 
-n appconfig-eshoponweb 
--key "ConnectionStrings:CatalogConnection" 
--secret-identifier https://<nome key 
vault>.vault.azure.net/Secrets/CatalogConnection 





IdentityConnection: 


# Criação da string de conexão no Key Vault 
az keyvault secret set 
--name IdentityConnection 
--vault-name keyvault-eshoponweb 
--value "Server=tcp:<replaceserver>,1433;..." 


# Criação da configuração da string de conexão referenciando 
# ao item do Key Vault criado anteriormente 
az appconfig kv set-keyvault 
-n appconfig-eshoponweb 
--key “ConnectionStrings: IdentityConnection" 
--secret-identifier https://<nome key 
vault>.vault.azure.net/Secrets/IdentityConnection 





OrderConnection: 


# Criação da string de conexão no Key Vault 


az keyvault secret set 
--name OrderConnection 
--vault-name keyvault-eshoponweb 


--value "Server=tcp:<replaceserver>,1433;...' 


# Criação da configuração da string de conexão referenciando 
# ao item do Key Vault criado anteriormente 
az appconfig kv set-keyvault 

-n appconfig-eshoponweb 

--key "ConnectionStrings:OrderConnection" 

--label "OrderApi" 

--secret-identifier https://<nome key 
vault>.vault.azure.net/Secrets/OrderConnection 





11.5 Configurar a proteção de dados da nossa 
aplicagao em ASP.NET Core 


Conforme informado no capítulo 1, nossa aplicação contempla um 
mecanismo de proteção de dados baseado em uma chave que fica 
armazenada em disco. Essa configuração é realizada no arquivo 
Startup.cs da aplicação web, conforme trecho de código a seguir. 


services.AddDataProtection() 
.PersistKeysToFileSystem( 


new DirectoryInfo( 
Configuration 
.GetSection("DataProtectionPath").Value) ); 





Com o intuito de aumentar a segurança dessa chave e garantir que 
a mesma chave seja utilizada por todas as instâncias da aplicação, 
vamos alterar essa configuração para utilizar o Azure Key Vault 
criado no tópico anterior. Armazenaremos a chave no Azure Storage 
Account criado anteriormente. Para isso, siga o passo a passo a 
seguir. 


Passo 1 


Os pacotes a seguir permitem o armazenamento de chaves 
compartilhadas entre várias instâncias de um aplicativo da web, 
sendo compartilhadas e podendo ser acessadas por múltiplos 
servidores. 


e Azure.Extensions.AspNetCore.DataProtection.Blobs 
e Azure.Extensions.AspNetCore.DataProtection.Keys 


Passo 2 


Altere a configuração de DataProtection NO arquivo startup.cs para: 


var dataProtectionConfig = new DataProtectionConfig() ; 
Configuration.Bind(DataProtectionConfig.CONFIG NAME, 
dataProtectionConfig); 
services.AddDataProtection() 
.PersistKeysToAzureBlobStorage( 


dataProtectionConfig.StorageAccountConnectionString, 

"dataprotection", "keystore") 
.ProtectKeyswWithAzureKeyVault ( 

new Uri(dataProtectionConfig.KeyVaultUri), 

new DefaultAzureCredential()); 





Passo 3 


Crie um contéiner novo para armazenarmos a chave: 


az storage container create 


-n dataprotection 
--account-name steshopdata 





Passo 4 


Adicione as novas chaves ao Azure App Configuration e Azure Key 
Vault: 


Storage Account Connection String: 


# Criação da string de conexão no Key Vault 
az keyvault secret set 
--name StorageAccountConnectionString 
--vault-name keyvault-eshoponweb 
--value "<valor da string de conexao do Storage Account>" 


# Criação da configuração da string de conexão referenciando 
# ao item do Key Vault criado anteriormente 
az appconfig kv set-keyvault 

-n appconfig-eshoponweb 


--key "DataProtection: StorageAccountConnectionString" 

--label "Web" 

--secret-identifier https://<nome key 
vault>.vault.azure.net/Secrets/StorageAccountConnectionString 





DataProtectionKey: 


# Criação da chave do Data Protection no Key Vault 
az keyvault key create 

--name DataProtectionkey 

--vault-name keyvault-eshoponweb 


# Criação da configuração da chave referenciando ao item do 
# Key Vault criado anteriormente 
az appconfig kv set 

-n appconfig-eshoponweb 

--key “DataProtection:KeyVaultUri" 

--label "Web" 


--value "https://<nome key 
vault>.vault.azure.net/keys/DataProtectionKey" 





11.6 Migragao da Versao do .NET para o 5.0 


Como recentemente tivemos o lançamento do NEI 5 e a solução 
da aplicação que estamos trabalhando contempla a versão 3.1 do 
.NET Core, resolvemos migrar para o .NET 5 seguindo a própria 
documentação da Microsoft, disponível no link: 
https://docs.microsoft.com/aspnet/core/migration/31-to-50. 


Além das alterações realizadas em nosso projeto, precisamos 
alterar os arquivos que contemplam o workflow do GitHub Action, 
para que o setup da versão do .NET utilizado seja do .NET 5. Para 
isso, devemos alterar a versão de 3.1.301 para 5.0.x, conforme 
exemplo a seguir. 


- name: Setup .NET Core 
uses: actions/setup-dotnet@v1 


with: 
dotnet-version: 5.0.x 





11.7 Resumo 


Neste capitulo: 


e Entendemos o conceitual de microsserviços e exemplificamos a 
quebra do domínio de pedidos, que estava acoplado ao 
monolito, em um serviço apartado. 

e Utilizamos o Azure App Configuration e o Azure Key Vault para 
facilitar a gestão e centralização das configurações de nossos 
serviços. 

e E, por fim, migramos toda a aplicação da versão do NEI Core 
3.1 para o NEI 5. 


CAPITULO 12 
Introdução ao contêiner 


Escrito por Christiano Donke, Jose Otavio Quaglio e Rafael 
Andrade. 


CENÁRIO 


No capítulo anterior, foi abordada a separação do domínio de 
pedidos do nosso monólito. Com essa separação, teremos 
partes da aplicação voltadas para cada domínio de negócio, 
então poderemos criar um contêiner para cada uma dessas 
partes. 


Neste capítulo, abordaremos: 


e Introdução ao contêiner (Docker). 

e Criação das imagens. 

e Publicação das imagens em um repositório privado. 

e Alteração do processo de integração contínua, adicionando 
uma automação para a criação e publicação das imagens 
de contêineres. 





Como explicado anteriormente, a adoção de microsserviços em 
nossa aplicação requer uma gestão mais robusta e eficaz para 
garantir a disponibilidade e escalabilidade da solução. Vamos iniciar 
o capítulo com o assunto sobre contêineres. 


12.1 O que é? 


Se pararmos para pensar nos primórdios dos grandes data centers, 
tínhamos dois cenários. Um era uma quantidade de computadores 


caríssimos subutilizados. O outro era o mesmo monte de 
computadores igualmente caros que ja nao aguentavam mais a 
carga. Esse segundo cenario era um impeditivo para muitas 
empresas, justamente pelo custo e os prazos para compra de novos 
hardwares. 


Passou-se o tempo e surgiu a virtualização de servidores. Nesse 
modelo, podemos ter diversos servidores distintos em execução 
dentro de um único servidor. Essas máquinas virtuais apenas 
compartilham os recursos de hardware, sem uma interferir na outra. 
Ao mesmo tempo em que isso trouxe uma solução, trouxe um 
problema. Como cada máquina virtual era como um servidor 
independente, tínhamos a instalação do sistema operacional, as 
dependências, atualização de antivírus, patches e tudo mais uma 
por uma, além do consumo de memória, disco e processamento. 


Máquina virtual Maquina virtual 





Figura 12.1: Estrutura da máquina virtual. 


Vendo esse cenario, em 2008, em Palo Alto, California, uma 
empresa chamada Docker Inc criou a plataforma de contéineres 
para rodar em Linux. Essa plataforma se furtava de compartilhar as 
partes comuns dos servidores, como o hardware e alguns trechos 
do sistema operacional, como a pasta /bin OU c:\windows , sem a 
necessidade de replicar tudo. 
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Figura 12.2: Estrutura de contéineres. 


Desse modo, o tamanho das imagens (instalações) reduziu 
drasticamente, pois não precisava mais copiar todo o sistema 
operacional. A parte de gerenciamento também foi beneficiada, pois 
atualizações do sistema operacional já eram afetadas nas 
instâncias. 


Ao executar, em razao de contéineres consumirem menos recursos, 
os servidores conseguem trabalhar uma quantidade bem maior de 
instâncias quando comparados a máquinas virtuais. 


Nomenclaturas 


Antes de continuarmos, precisamos definir alguns termos comuns. 


Contêineres rodam em um serviço, o daemon. Esse é o motor de 
execução do Docker. O servidor onde ele roda é chamado de host. 


Como o serviço pode ser executado remotamente, o shell onde eu 
executo os comandos enviados para o host é chamado de cliente. 


A imagem é a compilação das descrições, dependências e regras 
para executar a aplicação. 


Quando uma imagem é executada no Docker, ela passa a se 
chamar contêiner. 


As imagens podem ser armazenadas localmente, em serviços 
corporativos ou na nuvem, em um serviço chamado registro. Ele é 
responsável por centralizar o armazenamento das imagens. 


Sobre as imagens 


Fundamentalmente, um contêiner nada mais é que um processo em 
execução, adicionado de algumas funcionalidades encapsuladas 
para manter o isolamento entre contêineres. 


Em um ambiente de conteinerização, tudo acontece ao redor das 
imagens. A imagem empacota tudo o que é necessário para rodar 
uma aplicação, como o código, executáveis, dependências e 
qualquer outro objeto de sistema necessário para sua execução. 


A imagem é composta por uma série de camadas. A primeira é 
chamada de base. Ela é fornecida pelas fabricantes, como a 
Microsoft para contêineres Windows ou a Canonical para os Ubuntu. 
Depois dela, cada instrução para a criação da imagem vira uma 


camada distinta e única. Todas as camadas são apenas leitura, 
exceto a última, onde pode ocorrer gravação temporária, já que os 
dados serão perdidos ao encerrar. 
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Figura 12.3: Modelo de camadas. 


Esse sistema de camadas ajuda na reutilização. Como cada 
camada vira um arquivo, não é necessário copiá-lo diversas vezes 
para reutilizar, já que os arquivos são únicos. Caso ele seja utilizado 
em outros locais, é feita simplesmente uma referência, sem duplicar. 
Isso impacta diretamente na quantidade de espaço para 
armazenamento em disco. 


Criação de imagens 


As imagens são construídas a partir do arquivo Dockerfile , que é 
um arquivo de texto que contém todas as instruções necessárias 
para produzir a imagem. Fazendo uma analogia, O Dockerfile é 
como uma receita de bolo para um contêiner. 


Cada instrução dá origem a uma camada apenas de leitura. Elas 
são empilhadas e cada uma é um diferencial (delta) para a camada 
anterior. 


Essas instruções têm um formato específico e são executadas na 
ordem em que são declaradas. 


# Comentário 


INSTRUÇÃO argumento 





O pockerfile deve começar com a instrução From . Ela define a 
imagem base e inicia um estágio. 


FROM NOME IMAGEM: TAG 





A instrução workorr define o diretório atual dentro da imagem. É 
como se internamente executasse o comando cd (€ mkdir, caso o 
diretório não exista). Todos os comandos executados a partir dessa 
instrução trabalharão dentro desse contexto. 


WORKDIR /app 


Arquivos podem ser copiados para dentro da imagem de dois 
modos. Com a instrução app OU copy. A principal diferença entre 
eles, é que o app aceita URL para copiar arquivos remotos. 


ADD <origem> <destino> 


COPY <origem> <destino> 





Por exemplo: 


# Copiar o arquivo textfile.txt do host 
# para o diretorio atual no contéiner 
ADD textfile.txt . 


# Copiar o arquivo textfile1.txt presente 
# na URL para o diretorio atual no contéiner 
ADD http://contoso.com/textfilel.txt . 


# Copiar o arquivo textfile2.txt do host 
# para o diretório atual no contéiner 
COPY textfile2.txt . 





A instrução run é responsável por executar comandos no contêiner. 
Qualquer comando de PowerShell, Command ou Bash pode ser 
executado (de acordo com o SHELL que estiver executando). 


RUN <comando> 
RUN ["<executavel>", "<argumento1>", ..., "<argumento N>"] 





Por ultimo, a instrução entrypornt define qual é o executável que vai 
ser executado quando o contéiner for inicializado. 


ENTRYPOINT[ "<executavel>","<argumento1>",...,"<argumento N>"] 





Não confunda o entrypoinT (OU CMD) como run. O último sera 
executado durante a construção do contéiner apenas. Os outros, 
quando o contêiner for executado. 


Criação de uma imagem de contêiner 


Temos duas abordagens para a criação de uma imagem de 
contêiner. 


Podemos compilar nossa aplicação pelas vias normais (através do 
próprio Microsoft Visual Studio ou por linha de comando) e, após 
isso, adicionar o resultado da compilação dentro de uma imagem de 
contêiner, conforme o exemplo a seguir. 


FROM mcr.microsoft.com/dotnet/aspnet:5.0-buster-slim 
WORKDIR /app 


COPY . 
ENTRYPOINT ["dotnet", "mywebapp.d11" | 





Ou podemos criar um Dockerfile que realiza todos os 
procedimentos dentro de contêiner. Este cenário é chamado de 
multi-stage builds, conforme exemplo a seguir. 


FROM mcr.microsoft.com/dotnet/sdk:5.0-buster-slim as BUILD 


WORKDIR /src 
COPY *.csproj ./ 
RUN dotnet restore 


COPY . ./ 
RUN dotnet build 
RUN dotnet publish -c Release -o /app 


FROM mcr.microsoft.com/dotnet/aspnet:5.0-buster-slim 
WORKDIR /app 

COPY --from=BUILD /app . 

ENTRYPOINT ["dotnet", "mywebapp.d11" | 





Com a receita do bolo pronta, precisamos falar para o Docker 
Engine construir a imagem. Para isso, usamos o seguinte comando: 


docker build [OPÇÕES] Caminho Dockerfile CONTEXTO 





Como opções, existem diversos parâmetros a serem passados, mas 
focaremos em apenas dois: 


e --tag ou -t: nome e opcionalmente a tag da imagem, no formato 
nome:tag. 

e --file ou -f: nome do Dockerfile . O padrão é simplesmente 
Dockerfile na pasta atual. Se for qualquer coisa diferente disso, 
deve ser informado. 


O contexto é o caminho de onde os arquivos serão copiados. 
Normalmente, é a partir da pasta do Dockerfile . Todos os arquivos 
ali serão enviados para o Docker Engine e estarão presentes na 
imagem somente se forem copiados com copy OU ADD. 


E com isso temos a nossa imagem criada localmente. 


12.2 Armazenamento e distribuigao de imagens 


Agora que ja temos as imagens criadas, precisamos entender como 
acontece a distribuição delas, afinal, "na minha maquina funciona" 
não é mais uma desculpa válida. 


Todas as imagens de contêineres devem ficar armazenadas em um 
Registry . Ele é uma aplicação stateless e server-side de alta 
escalabilidade que permite armazenar e distribuir as imagens. O 
Registry garante que as imagens sejam buscáveis, oferecendo 
versionamento e disponibilidade. 


A seguir, vamos explicar os três diferentes tipos de registros que 
podemos utilizar. 


Tipos de registro 


Registro local (on-premises) 


É possível ter um registro dentro do seu próprio data center 
simplesmente executando um contêiner como um serviço de 
registro. 


docker run -d 
-p 5000:5000 
--restart=always 
--name registry 
-v /mnt/registry:/var/lib/registry 


registry:2 





Essa opção é válida para garantir agilidade e consumo de banda, 
mas ela tem o seu contra também, que é a administração de toda a 
infraestrutura para o funcionamento desse serviço. 


Registro público 


Outra opção é armazenar diretamente no Docker Hub 
(https://hub.docker.com) que, por padrão, oferece gratuitamente o 
armazenamento de imagens públicas, sem restrição de acesso. 
Esse é o repositório central de imagens com acesso global. 


É lá que ficam as imagens base dos sistemas operacionais e de 
sistemas, como NGINX, Busybox e milhares de outros modelos e 
exemplos. 


Registro privado 


Certamente, em um ambiente corporativo, não queremos as 
imagens dos sistemas disponíveis publicamente. Para isso, 
podemos usar o Azure Container Registry (ACR). 


Esse é o serviço gerenciado da Azure para armazenamento de 
imagens, que permite controle granular sobre quem pode baixar ou 
enviar imagens ou administrar. Além da integração com Azure 
Active Directory, também não é preciso se preocupar com 
gerenciamento de ambiente e armazenamento. 


Criação do Azure Container Registry 


Para criar um ACR, vamos executar a seguinte linha de comando, 
onde especificamos o grupo de recursos criado anteriormente e o 
nome do nosso ACR. Vamos habilitar o modo admin para que seja 
possível conectar-se remotamente a esse recurso através, por 
exemplo, do GitHub Action. 


az acr create 


--resource-group rg-eshoponweb-cloud 


--name creshoponweb 
--sku Basic 
--admin-enabled true 





Para acessar o ACR, basta fazer login utilizando o Azure CLI: 


az acr login --name creshoponweb 





Com isso, ele valida as credenciais no Azure, no ACR e no Docker 
Engine automaticamente. 


12.3 Como criar as imagens de contêiner da 
solução 


Até esse momento, já entendemos o conceitual sobre contêineres, 
aprendemos a criar arquivos contendo as instruções para gerar 
nossa imagem ( Dockerfile ) e, por último, entendemos também que 
precisamos armazenar as imagens geradas em algum local seguro, 
ao qual chamamos de registro (seja ele privado ou público). 


Nos capítulos anteriores, foi abordado também o conceitual de 
microsserviço e neste tópico foi realizado o desacoplamento do 
domínio de negócio chamado de Order. Com isso, criaremos as 
seguintes imagens de contêineres. 


e Web. 
e PublicApi. 
e OrderApi. 


O primeiro passo é a escolha certa da imagem base. Como estamos 
trabalhando com uma versão do ASP.NET que é multiplataforma 
(.NET 5), optaremos por ter uma imagem base com o sistema 
operacional Linux. A Microsoft disponibiliza diversas imagens para 
Linux baseadas em diferentes distribuições, como Debian 9 e 10, 
Ubuntu 20.04 e 18.04, Alpine 3.12, entre outras. Para o nosso 
cenário, optaremos por utilizar a imagem base: 
mcr.microsoft.com/dotnet/as pnet:5.0-buster-slim 


Vale ressaltar que, apesar de termos a opção de utilizar imagens 
com a tag latest , não é uma boa prática utilizá-las, pois elas podem 
sofrer atualizações e, com isso, poderemos ter algum impacto em 
nossa aplicação. A recomendação é que haja uma gestão das 
imagens bases pelas empresas para garantir que todas estejam 
atualizadas e testadas, com o intuito de mitigar problemas na 
execução da aplicação e na segurança do contêiner. 


Vamos começar pela aplicação Web. 
Dockerfile: Web 


Crie um arquivo chamado bDockerfile (isso mesmo, sem extensão) 
na pasta do projeto Web (c:\Repos\eShopOnWeb\src\Web). O 
Dockerfile é um arquivo texto e a primeira instrução deve ser a 
imagem base. 


FROM mcr.microsoft.com/dotnet/aspnet:5.0-buster-slim 





Logo depois, devemos definir o caminho de trabalho e copiar os 
arquivos, que foram gerados pelo resultado da compilação, para 
dentro do contêiner. 


WORKDIR /app 


COPY WebPublish . 





Com todos os arquivos copiados, basta informar qual é o comando 
que vai ser executado quando inicializar um novo contêiner a partir 
dessa imagem. 


ENTRYPOINT [ "dotnet", "Web.dll” ] 





Dockerfile: PublicApi 


O processo do projeto PublicAPI é praticamente o mesmo. Crie um 
arquivo chamado bDockerfile na pasta do projeto PublicApi 
(c:\Repos\eShopOnWeb\src\PublicApi). Neste arquivo, trocaremos 
somente o caminho da pasta onde se encontra o projeto do 
PublicAPI e o nome da DLL que servirá como nosso entrypoint . 


FROM mcr.microsoft.com/dotnet/aspnet:5.0-buster-slim 
WORKDIR /app 


COPY PublicApiPublish . 
ENTRYPOINT [ "dotnet", "PublicApi.dll" | 





Dockerfile: OrderApi 


O processo do projeto OrderApi é praticamente o mesmo. Crie um 
arquivo chamado bDockerfile na pasta do projeto OrderApi 
(c:\Repos\eShopOnWeb\src\OrderApi). Neste arquivo, trocaremos 
somente o caminho da pasta onde se encontra o projeto do 
OrderApi e o nome da DLL que servirá como nosso entrypoint . 


FROM mcr.microsoft.com/dotnet/aspnet:5.0-buster-slim 
WORKDIR /app 
COPY OrderApiPublish . 


ENTRYPOINT [ "dotnet", "OrderApi.dl1" ] 





Construção das imagens 


Temos três arquivos Dockerfile : Um em 
c:\Repos\eShopOnWeb\src\Web, outro em 
ciReposteShopOnWeblsrclPublicApi e o outro em 
c:\Repos\eShopOnWeb\src\ OrderApi. Agora vamos efetivamente 
montar a imagem de contêiner como vimos no tópico Criação de 
imagens. 


Criaremos as imagens a partir da raiz da solução 
(ciReposleShopOnWWeb). Para isso, precisamos dar um nome e 
definir uma tag para cada uma das imagens. Como forma de 
padronização, vamos prefixar o nome com eshoponweb (precisa ser 
tudo minúsculo) e como tag , utilizando a versão da nossa aplicação 
em contêiner, que será 1.0. 


docker build -t eshoponweb-web:1.0 
-f .\src\Web\Dockerfile . 


docker build -t eshoponweb-publicapi:1.0 
-f .\src\PublicApi\Dockerfile . 


docker build -t eshoponweb-orderapi:1.0 
-f .\src\OrderApi\Dockerfile . 





Depois, verificamos as imagens criadas: 


PS C:\Repos\eShopOnWeb> images eshoponweb* 
REPOSITORY IMAGE ID CREATED 
eshoponweb-orderapi : b985cb38ea5a 52 seconds ago 


eshoponweb-publicapi - c2823e28a998 2 minutes ago 
le shoponweb-web a 87196d1c8074 4 minutes ago 





Figura 12.4: Imagens criadas. 
Enviando imagens para o ACR 


Uma vez que temos nossas imagens criadas, é hora de fazer com 
que elas sejam acessíveis de outros lugares. Para isso, precisamos 
enviá-las para o nosso repositório de imagens privado, o Azure 
Container Registry. 


Para que possamos fazer isso, precisamos alterar o nome delas 
seguindo o seguinte padrão. 


[LOGIN SERVER]/nome: [tag] latest] 





O LOGIN SERVER, NO caso, é a URL do nosso ACR, que foi criado no 
tópico Criação do Azure Container Registry. 


Caso não saiba o endereço, você pode executar o seguinte 
comando para obtê-lo. 


az acr list -g rg-eshoponweb -o table 


PS C:\Repos\eShopOnWeb> az acr list rg-eshoponweb table 
AME RESOURCE GROUP LOCATION SKU LOGIN SERVER CREATION DATE ADMIN ENABLED 





reshoponweb rg-eshoponweb brazilsouth Basic creshoponweb.azurecr.io 2020-10-18719:10:16Z True 


Figura 12.5: Endereço do ACR. 


Agora precisamos alterar o nome de nossas imagens para receber o 
caminho do servidor. Para isso, utilizaremos o comando tag, que 


realiza a criação de uma nova imagem a partir de outra. 


docker tag ORIGEM[:tag] DESTINO[ :tag] 





Desse modo, teremos: 


docker tag eshoponweb-web:1.0 
creshoponweb.azurecr.io/eshoponweb-web:1.0 


docker tag eshoponweb-publicapi:1.0 
creshoponweb. azurecr.io/eshoponweb-publicapi:1.0 


docker tag eshoponweb-orderapi:1.0 
creshoponweb.azurecr.io/eshoponweb-orderapi:1.0 





Quando fazemos isso, temos as seguintes imagens: 


E Administrator: Windows PowerShell 

PS C:\Repos\eShopOnWeb> images 

REPOSITORY IMAGE ID CREATED SIZE 
creshoponweb.azurecr. io/eshoponweb-orderapi 5 b985cb38ea5a 6 minutes ago 119MB 
eshoponweb-orderapi 5 b985cb38ea5a 6 minutes ago 119MB 
<none> c9d215c6c464 6 minutes ago 727MB 
creshoponweb.azurecr. io/eshoponweb-publicapi c2823e28a998 7 minutes ago 147MB 


eshoponweb-publicapi A c2823e28a998 7 minutes ago 147MB 
<none> <none> 2e06715516f0 7 minutes ago 1.11GB 
creshoponweb.azurecr.io/eshoponweb-web 1.0 87196d1c8074 10 minutes ago 190MB 
eshoponweb-web 1.0 87196d1c8074 10 minutes ago 190MB 
<none> <none> e1bc71885071 10 minutes ago 1.63GB 





Figura 12.6: Exemplo de visualização das imagens após a criação. 


Note que a coluna IMAGE ID não se altera entre as imagens. Isso 
quer dizer que ele reutilizou a imagem anterior e não duplicou as 
imagens, logo o armazenamento não se multiplicou. 


Agora temos as imagens preparadas para serem enviadas ao ACR. 
Basta enviá-las através do comando push (não esqueça de se 
conectar ao ACR, caso não tenha se conectado): 


docker push NOME[:TAG] 





Exemplo de conexao: 


az acr login --name creshoponweb 


PS C:\Repos\eShopOnWeb> az acr login eshoponwebacr 
Login Succeeded 





Figura 12.7: Retorno após a execução do comando. 


Com isso, temos: 


docker push creshoponweb.azurecr.io/eshoponweb-web:1.0 


docker push creshoponweb.azurecr.io/eshoponweb-publicapi:1.0 


docker push creshoponweb.azurecr.io/eshoponweb-orderapi:1.0 





Se formos verificar o Portal do Azure, temos as imagens 
armazenadas em nosso repositório privado. 


Home > Resource groups > rg-eshoponweb-cloud > creshoponweb 


on, creshoponweb | Repositories & 


Container registry 





P Search (Ctrl+/) | < O Refresh 





@ Overview D earch to filter repositories ... 





E Activity log Repositories Ty 


fa Access control (IAM) eshoponweb-orderapi 


@ Tags eshoponweb-publicapi 


& Quick start eshoponweb-web 


g Events 


Figura 12.8: Imagens publicadas na área de repositórios do ACR. 


12.4 Automatizar a criação das imagens e envio 
para registro 


Como já temos um arquivo de workflow do GitHub Action chamado 
eshoponweb-cd.yml , precisaremos alterá-lo para automatizar o 
processo de geração e publicação das imagens em nosso registro 
privado. 


O primeiro passo é fazer o login no nosso registro privado do Azure 
Container Registry. Para isso, precisamos antes adicionar os dados 
do ACR nos Secrets do GitHub. Para isso, no menu Settings, 
devemos adicionar os seguintes segredos para que essas 
informações sensíveis não fiquem visíveis para todos. 


e Usuário, chamado acr_USERNAME . 
e Senha, chamado AGE PASSWORD . 
e Servidor, chamado acR SERVER. 


Code Issues Pull requests Actions Projects 1 Security Insights @ Settings 


Options Secrets 
Manage access 

Secrets are environment variables that are encrypted anc 
Security & analysis use these secrets in a workflow. 
Secrets are not passed to workflows that are triggered by 
Branches 
Webhooks 

Repository secrets 


Notifications 


Integrations A ac R_PASSWORD 
Deploy keys 
Ê ACR SERVER 


Secrets 


Actions Ê ACR USERNAME 


Figura 12.9: Listagem dos segredos no GitHub. 


O próximo passo é fazer o login no ACR. Criamos um passo 
chamado azure Container Registry Login, que usará o módulo 
azure/docker-login@ v1, e utilizará as credenciais criadas 
anteriormente como segredos no GitHub. 


- name: Azure Container Registry Login 
uses: azure/docker-login@v1 
with: 


login-server: ${{ secrets.ACR SERVER }} 
username: ${{ secrets.ACR_USERNAME }} 
password: ${{ secrets.ACR PASSWORD }} 





Vamos agora Criar OS passos: 


e Build and Push - Web. 


e Build and Push - PublicApi. 
e Build and Push - OrderApi. 


Nesta etapa, marcaremos essas imagens com duas tags. A latest 
para atualizar a ultima imagem enviada anteriormente e outra com 
um código único gerado durante a execução do workflow pelo 
próprio GitHub (SHA). Logo em seguida, enviaremos as imagens 
direto para o ACR. Utilizaremos a latest apenas para simplificar o 
exemplo mostrado. 


- name: Build and Push - Web 
run: | 
docker build 
--tag ${{ secrets.ACR SERVER }}/eshoponweb-web: latest 


--tag ${{ secrets.ACR SERVER }}/eshoponweb-web:${{ github.sha }} 
-f ./src/Web/Dockerfile . 
docker push ${{ secrets.ACR SERVER }}/eshoponweb-web: latest 
docker push ${{ secrets.ACR SERVER }}/eshoponweb-web: ${{ 
github.sha }} 





Os próximos passos serão parecidos. Alteraremos apenas qual 
aplicação sofrerá a ação, ou seja, trocaremos apenas os nomes. 


name: Build and Push - PublicApi 
run: | 
docker build 
--tag ${{ secrets.ACR SERVER }}/eshoponweb-publicapi: latest 
--tag ${{ secrets.ACR SERVER }}/eshoponweb-publicapi:${{ 
github.sha }} 
-f ./src/PublicApi/Dockerfile . 
docker push ${{ secrets.ACR SERVER }}/eshoponweb-publicapi: latest 
docker push ${{ secrets.ACR SERVER }}/eshoponweb-publicapi:${{ 
github.sha }} 


- name: Build and Push - OrderApi 
run: | 
docker build 
--tag ${{ secrets.ACR SERVER }}/eshoponweb-orderapi: latest 
--tag ${{ secrets.ACR SERVER }}/eshoponweb-orderapi: ${{ 
github.sha }} 
-f ./src/OrderApi/Dockerfile . 
docker push ${{ secrets.ACR SERVER }}/eshoponweb-orderapi: latest 
docker push ${{ secrets.ACR SERVER }}/eshoponweb-orderapi: ${{ 
github.sha }} 





O arquivo do GitHub Action ficou da seguinte forma. 





name: eshoponweb-cd 


on: 
push: 
branches: [master] 
pull request: 
branches: [master] 


jobs: 
build: 
runs-on: ubuntu-latest 


steps: 
- uses: actions/checkout(dv2 


- name: Setup .NET Core 
uses: actions/setup-dotnet@v1 
with: 
dotnet-version: 5.0.x 


- name: Install dependencies 
run: dotnet restore 


- name: Build Public API 
run: dotnet build src/PublicApi/PublicApi.csproj 
--configuration Release --no-restore 


- name: Build Order API 
run: dotnet build src/OrderApi/OrderApi.csproj 
--configuration Release --no-restore 


- name: Build Web 
run: dotnet build src/Web/Web.csproj 
--configuration Release --no-restore 


- name: Test 
run: dotnet test UnitTests/UnitTests.csproj 
--no-restore --verbosity normal 


- name: Publish Public API 
run: dotnet publish src/PublicApi/PublicApi.csproj 
--configuration Release 
--output PublicApiPublish --no-restore 


- name: Publish Order API 
run: dotnet publish src/OrderApi/OrderApi.csproj 
--configuration Release 
--output OrderApiPublish --no-restore 


- name: Publish Web 
run: dotnet publish src/Web/Web.csproj 
--configuration Release 
--output WebPublish --no-restore 


- name: Azure Container Registry Login 
uses: azure/docker-login@v1 
with: 
login-server: ${{ secrets.ACR SERVER }} 
username: ${{ secrets.ACR USERNAME }} 
password: ${{ secrets.ACR PASSWORD }} 


- name: Build and Push - PublicApi 
run: | 
docker build 
--tag ${{ secrets.ACR SERVER }}/eshoponweb- 
publicapi:latest 
--tag ${{ secrets.ACR SERVER }}/eshoponweb-publicapi:${{ 
github.sha }} 
-f ./src/PublicApi/Dockerfile . 
docker push ${{ secrets.ACR SERVER }}/eshoponweb- 
publicapi:latest 
docker push ${{ secrets.ACR SERVER }}/eshoponweb- 
publicapi:${{ github.sha }} 


- name: Build and Push - OrderApi 
run: | 
docker build 
--tag ${{ secrets.ACR SERVER }}/eshoponweb-orderapi: latest 
--tag ${{ secrets.ACR SERVER }}/eshoponweb-orderapi:${{ 
github.sha }} 


-f ./src/OrderApi/Dockerfile . 
docker push ${{ secrets.ACR SERVER }}/eshoponweb- 
orderapi: latest 
docker push ${{ secrets.ACR SERVER }}/eshoponweb- 
orderapi:${{ github.sha }} 


- name: Build and Push - Web 
run: | 
docker build 


--tag ${{ secrets.ACR SERVER }}/eshoponweb-web: latest 
--tag ${{ secrets.ACR SERVER }}/eshoponweb-web: ${{ 
github.sha }} 
-f ./src/Web/Dockerfile . 
docker push ${{ secrets.ACR SERVER }}/eshoponweb-web: latest 
docker push ${{ secrets.ACR_SERVER }}/eshoponweb-web: ${{ 
github.sha }} 




















E com isso, temos nossas aplicações no ACR, prontas para serem 
usadas pelos orquestradores. 
«@, creshoponweb | Repositories | eshoponweb-web & 
Container registry Repository 
D Search (Ctrl+/) | ‘ © Refresh oO Refresh E Delete repository 
@ overview P Search to filter repositories ... cics 
É Activity log Repositories Gu Repository : eshoponweb-web 
Last updated date : 10/30/2020, 9:56 PM GMT-3 
E Access control (IAM) eshoponweb-orderapi 
O Search to filter tags .. 
@ Tags eshoponweb-publicapi ... ee 
4 
© Quick start eshoponweb-web bd 
$ Events latest 
a03 1laeeece0920725567 1b8303d74a54c0232aa1 
Settings 


Figura 12.10: Imagem de contêiner publicado no ACR. 


12.5 Resumo 


Neste capítulo, introduzimos o assunto de contêineres e, com isso, 
conseguimos realizar a conteinerização das três partes da aplicação 
(Web, PublicApi e OrderApi). Também disponibilizamos esses 
contêineres em nosso registro privado no Azure (Azure Container 
Registry) através de um fluxo automatizado criado no Github 
Actions. 


CAPITULO 13 
Orquestração de contêineres 


Escrito por Christiano Donke, Jose Otavio Quaglio e Rafael 
Andrade. 


CENÁRIO 


No capítulo anterior, realizamos a criação de alguns contêineres 
de nossa solução. Com esse cenário, modernizamos nossa 
infraestrutura com o intuito de facilitar a gestão, a monitoração e 
a implantação de nossa aplicação. 


Neste capítulo, abordaremos os seguintes assuntos: 


e Introdução ao Kubernetes. 

e Azure Kubernetes Service (AKS). 

e Monitoração dos recursos do cluster de AKS. 
e Infraestrutura como código. 





Agora que você já sabe o que é um contêiner e como executá-lo, 
provavelmente você está se perguntando: o que acontece se meu 
contêiner ou meu servidor parar de funcionar no ambiente 
produtivo? Como eu consigo melhorar esse processo, no caso de 
meu contêiner ou servidor parar de funcionar para que um novo 
assuma automaticamente”? Como eu consigo escalar meu contêiner 
e meu servidor de acordo com o consumo de recursos 
computacionais balanceando a carga entre eles? Em resumo, como 
eu consigo criar uma arquitetura de alta disponibilidade e 
escalabilidade com contêineres? 


Esses são questionamentos muito pertinentes ao pensar em um 
cenário em que você necessite garantir que sua aplicação tenha o 


minimo de indisponibilidade possivel e que consiga atender a 
demanda em determinados periodos de pico. 


Existem ferramentas que nos auxiliam nesses cenarios 
automatizando a gestão e proporcionando uma melhor monitoração 
dos contêineres, conhecidas como orquestradores. 


Conforme informado anteriormente, neste livro, vamos abordar a 
orquestração de contêineres por meio do Kubernetes. 


13.1 Introdução ao Kubernetes 


Quando falamos diretamente sobre orquestração e gerenciamento 
de contêineres, temos de início algumas perguntas para entender 
como o Kubernetes se aplica dentro da solução ou do processo de 
migração. Neste capítulo, nossa intenção é apresentar os principais 
recursos oferecidos por essa ferramenta. 


Pontos positivos ao considerar o Kubernetes: 


e Orquestra contêineres em diversas máquinas. 

e Melhora o uso do hardware permitindo a disponibilidade de 
recursos para execução dos aplicativos conforme demanda. 

e Possui agilidade para escalar aplicativos em contêineres. 

e Garante a integridade e recuperação dos aplicativos alocados 
em contêineres. 


Pontos negativos ao considerar o Kubernetes: 


e Possui curva de aprendizado maior. 
e Adiciona complexidade à infraestrutura. 
e Deve-se avaliar o custo-benefício ao considerar o Kubernetes. 


Antes de começarmos, é interessante conhecer um pouco mais 
sobre a origem do Kubernetes e como ele se tornou uma das 


principais ferramentas quando se fala em orquestração de 
contêineres. 


O precursor do Kubernetes foi um sistema interno do Google 
chamado Borg, desenvolvido pelos engenheiros Brendan Burns, 
Craig McLuckie e Joe Beda. Seu principal objetivo era melhorar a 
utilização de recursos computacionais e, assim, reduzir custos. Essa 
melhora na utilização de recursos computacionais era possível, 
porque o suporte a contêineres no kernel do Linux tornou-se cada 
vez mais viável. 


No ano de 2014, esse projeto se tornou público com a 
disponibilização de uma versão de código aberto, e empresas, como 
Microsoft, Red Hat, IBM e Docker se juntaram à comunidade do 
Kubernetes. 


Em julho de 2015, no evento OSCon em Oregon/EUA, foi 
apresentada para todos a primeira versão chamada Kubernetes 
v1.0. 





Figura 13.1: Logotipo oficial do Kubernetes apresentado em 2015 na OSCON. Origem do 
nome vem do grego **??Re???t??**, a palavra usada para "timoneiro”. 


No mesmo evento, o Google fez parceria com a Linux Foundation 
para formar a Cloud Native Computing Foundation (CNCF), eo 
Kubernetes v1.0 é doado para o CNCF, sendo o primeiro produto da 
união. 


CLOUD NATIVE 


COMPUTING FOUNDATION 


Figura 13.2: CNCF criada a partir da parceria do Google com a Linux Foundations 


Agora que conhecemos um pouco sobre a origem do Kubernetes, 
vamos apresentar com detalhes como é elaborada sua arquitetura e 
OS principais componentes para que você possa entender todos os 
termos e cenários do capítulo. 


Arquitetura do Kubernetes 


O Kubernetes é composto por diversos componentes que possuem 
tarefas bem definidas. Na imagem a seguir, mostramos a arquitetura 
macro do Kubernetes. É importante conhecer a função de cada 
componente desse modelo para acompanhar as demais 
explicações. 


O Kubernetes, conforme arquitetura disposta a seguir, possui vários 
componentes que executam dentro de um cluster. Vale ressaltar o 
conceito de cluster, que é um agrupamento de servidores que tem 
como propósito trabalhar em conjunto dando a sensação de agir 
como um único recurso. É diferente do conceito de orquestração. 
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Figura 13.3: Modelo da arquitetura do Kubernetes. 
Master 


Na imagem a seguir, destacamos apenas os componentes que 
compõem uma parte da arquitetura cnamada de Nó Master. Eles 


são responsáveis por passar as instruções que serão executadas 
pelo Nó Worker (veremos mais à frente). 


Nó Master 






-controller- 
-scheduler 
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Serviceaccaunts, etc, 
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Figura 13.4: Explicagao dos conceitos sobre o No Master. 
API Server 


O API Server é um componente muito importante para a arquitetura 
do Kubernetes. Ele usa JSON sobre HTTP como interface interna e 
externa para o Kubernetes e é responsável por processar e validar 

as solicitações REST e atualizar o estado dos objetos da API no 


etcd (usado para armazenamento de dados no cluster para apoiar 
as funcionalidades do Kubernetes), permitindo que os clientes 
configurem cargas de trabalho e contêineres nos nós. 


Controller Manager 


O Controller Manager, demonstrado na imagem anterior, tem como 
finalidade executar os controladores do Kubernetes. Um controlador 
serve para se comunicar com a API Server em rotinas, por exemplo, 
de criação, atualização ou exclusão de recursos que gerenciam os 
pods. Temos como exemplos de controlador os itens mostrados a 
seguir. 


e DaemonSet: garante que os nos executem uma cópia de um 
pod em cada um deles. 

e Replication Controller: garante que um número de réplicas de 
pods configurado esteja em execução ao mesmo tempo 
(voltado à disponibilidade). Caso algum pod esteja com algum 
problema e pare de executar, o Controller verificará que o 
Replication Controller não contêm o número de réplicas 
desejado e provisionará os pods faltantes até atingir o estado 
desejado. Atualmente é recomendado a utilização do item 
Deployment em vez de Replication Controller que por sua vez, 
automaticamente, configura um ReplicaSet, ao qual garante o 
número de réplicas de pods configurados. 


Scheduler 


O Scheduler tem a função de distribuir a demanda de trabalho entre 
todos os nós que ele gerencia. Ele avalia o uso de recursos em 
cada nó para garantir que a carga de trabalho não exceda os 
recursos disponíveis. 


Worker 


Um nó Worker é uma máquina responsável por executar tarefas no 
Kubernetes e pode ser tanto uma máquina virtual como física. Cada 
nó é gerenciado pelo Master. Um único nó pode ter um número 


limitado de pods, e o Master do Kubernetes organiza o 
agendamento dos pods entre os nos do cluster (através do 
Scheduler). 


No Worker 


Kubelet Kube-proxy 


Pod 


ezz 
Containers 


DD 





eei E E (a a SS bd ien ege Ge e SE 


j 
| 
| 
i 
| 
| 
i 
| 
| 
i 
l 
| 
i 
| 
| 
i 
| 
| 
i 
| 
| 
i 
| 
| 
i 


pe o pz m pe pe, pe pe pe, pe pe pe, o pe ë pe pe pz, m pe pe, m pe pz pe pe pz pi 


Figura 13.5: Explicação dos conceitos sobre o Nó Worker. 
Kubelet 


É um agente que roda em cada nó do cluster. Carrega um conjunto 
de especificações (também conhecido como PodSpecs) e garante 
que os contêineres descritos nesses arquivos estejam funcionando. 
Existe atualmente uma ferramenta conhecida como kube-advisor, 
que, entre outras funções, pode identificar a ausência de recursos 
no PodSpecs. 


Kube-proxy 


O kube-proxy é um proxy de rede que roda em cada nó do cluster. 
Sua estrutura mantém as regras de rede no host e faz o 
encaminhamento de conexões. O kube-proxy faz o 
encaminhamento de stream TCP, UDP e SCTP simples ou 
encaminhamento Round-Robin de TCP, UDP e SCTP em um 
conjunto de back-ends. 


Round-Robin é um algoritmo onde cada tarefa pronta é executada 
turno a turno em uma fila cíclica por um intervalo de tempo limitado, 
que consiste em distribuir as requisições de maneira sequencial 
entre os recursos. 


Alguns recursos do Kubernetes que utilizaremos neste projeto 


Namespace 


O namespace é caracterizado como uma divisão lógica onde todos 
os recursos criados serão agrupados. Caso não seja informado o 
namespace na criação de um recurso, o namespace utilizado será o 
"default". 


Pod 


Um pod pode ser classificado como um grupo de um ou mais 
contêineres implantados em um único nó. Observe, na imagem 
demonstrada anteriormente, um pod contendo três contêineres e 
outro contendo apenas um, mas ambos em pods separados. Isso 
depende muito de como sua aplicação está estruturada e qual o seu 
plano de escalonamento de recursos. 


Essa separação lógica permite: 


e Compartilhamento de rede com um endereço IP de cluster 
exclusivo. 
e Armazenamento compartilhado. 


e Informações sobre como executar cada contêiner, como a 
versão da imagem de cada contêiner ou portas específicas a 
serem usadas. 


Service 


Um service (ou serviços em português) no Kubernetes é um 
conceito que define um conjunto lógico de pods e uma política para 
a interação com eles. 


O conjunto de pods agrupados por um serviço é determinado por 
um seletor através de label. Cada pod possui um endereço IP único 
e estes não são expostos fora do cluster sem um service. Em 
resumo, os serviços permitem que seus aplicativos recebam tráfego 
de rede. Os serviços podem ser expostos de diferentes maneiras, 
especificando o tipo de exposição através do atributo type, como por 
exemplo: LoadBalancer. 
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Figura 13.6: Exemplo do uso de Services na arquitetura do Kubernetes. 


Ingress Controller 


Uma outra forma de expor uma aplicação através de rotas HTTP e 
HTTPS de fora do cluster para recursos que estão disponíveis 
internamente. Ele funciona de forma muito parecida com um 
roteador para acessar os serviços do Kubernetes. O Ingress 
Controller utiliza o recurso de ingress para gerenciar as regras de 
roteamento para um ou vários serviços disponíveis no cluster. Neste 
recurso é possível configurar um redirecionamento específico para 
cada DNS, como também configurar o certificado TLS que será 
utilizado para requisições HTTPS. 
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Figura 13.7: Exemplo do uso de Ingress Controller na arquitetura do Kubernetes. 


13.2 Introdução ao Azure Kubernetes Service 


Conforme explicado no tópico anterior, o Kubernetes é um software 
open source utilizado para orquestrar e escalar aplicações que 
executam como contêineres. No Azure, o Kubernetes tem o nome 
de Azure Kubernetes Service (AKS), um serviço gerenciado que traz 


em seu catálogo uma gama de recursos além do produto original, os 
quais podem auxiliar na gestão de sua aplicação em todos os 
ambientes. 


Criando e conectando-se ao cluster do AKS 


Como nossa aplicação se trata de um e-commerce para o qual 
necessitamos garantir alta disponibilidade e escalabilidade, vamos 
criar dois node pools no nosso cluster de AKS. O node pool é a 
forma como o AKS trata um conjunto de máquinas que contém a 
mesma configuração, seja ela relacionada ao sistema operacional 
(Windows ou Linux) e/ou à família de máquinas. Um outro ponto 
bastante interessante é que, ao utilizar node pools, podemos 
separar os recursos do sistema do Kubernetes dos recursos da 
aplicagao e, com isso, teriamos nos dedicados ao sistema e a 
aplicagao, garantindo isolamento e um melhor uso dos recursos 
computacionais. 


Como você deve ter visto nos tópicos anteriores, o Kubernetes 
contempla componentes que são necessários para o seu 
funcionamento. Caso os nós do cluster não possuam recursos 
computacionais suficientes, os pods podem falhar e 
consequentemente sua aplicação poderá ficar indisponível. Por isso, 
recomendamos que sejam realizados vários testes para garantir que 
a família de máquina virtual utilizada seja a ideal para o cenário da 
sua aplicação. 


No capítulo de contêineres, foi abordada a criação de um repositório 
de imagens. Como o AKS tem uma fácil integração com outros 
recursos do Azure e precisaremos obter as imagens da aplicação 
desse repositório, vamos vincular o recurso de Azure Container 
Registry criado anteriormente ao nosso cluster. 


Para o primeiro node pool, que será o de sistema, vamos criar um 
cluster com um grupo (node pool) contendo duas máquinas. Como 
esse grupo será dedicado apenas aos recursos do Kubernetes, 
vamos utilizar a família de máquina padrão, que é a standard DS2 v2. 


Sendo assim, nao precisaremos informar a familia de maquina no 
comando a seguir. 


az aks create 


--resource-group rg-eshoponweb-cloud 


--name aks-cluster 

--nodepool-name nodesystem 

--node-count 2 

--attach-acr creshoponweb 
--enable-managed-identity 

--network-plugin kubenet 

--dns-name-prefix "aks-cluster-eshoponweb" 
--enable-rbac true 





Após criado o cluster de AKS com o primeiro node pool, precisamos 
realizar a alteração da configuração para que ele tenha o 
comportamento e execute somente os recursos de sistema do 
Kubernetes. 


az aks nodepool update 
-g rg-eshoponweb-cloud 
--cluster-name aks-cluster 


-n nodesystem 
--mode system 





Como forma de exemplificar, no segundo node pool, vamos criar um 
grupo de máquinas contendo inicialmente dois nós, sendo escalável 
até cinco nós. Vale ressaltar que recomendamos que seja realizado 
um teste de carga na aplicação em um ambiente de Kubernetes, 
com a finalidade de entender quantos nós serão necessários para 
aguentar a quantidade de requisições em sua média de uso. 


Você se lembra que, no início deste livro, a aplicação foi para o 
Azure como laaS? Naquele capítulo inicial foi abordada a criação de 


máquinas virtuais utilizando a familia F-series, que é otimizada para 
o consumo de CPU. No ambiente do Kubernetes, vamos manter 
essa família e utilizar máquinas virtuais com o tamanho 
Standard Ede v2 . Habilitaremos também a funcionalidade de 
escalabilidade automática do cluster. 


az aks nodepool add 


--resource-group rg-eshoponweb-cloud 
--cluster-name aks-cluster 

--name nodeapp 

--node-vm-size Standard F4s v2 
--node-count 2 
--enable-cluster-autoscaler 
--min-count 2 

--max-count 5 

--mode user 





Após os node pools terem sido criados, precisamos nos conectar ao 
cluster com a finalidade de manipular/criar os recursos dentro do 
cluster de Kubernetes. A conexão ao cluster nada mais é que a 
criação de um contexto de conexão em nossa máquina que será 
utilizado pelo executável kubect1 para realizar a 
manipulação/criação dos recursos no cluster. 


az aks get-credentials 


--resource-group rg-eshoponweb-cloud 


--name aks-cluster 





Criando nosso ponto de entrada do cluster (NGINX) 


Antes de iniciarmos a criação dos componentes dentro do nosso 
cluster, precisamos entender a arquitetura da solução que estamos 
trabalhando e, a partir disso, criar os recursos dentro do AKS. 


Como as imagens de contêiner ja foram criadas e adicionadas ao 
nosso registro privado de imagens (ACR), precisaremos desenhar 
como esses contêineres estarão dispostos em forma de pods no 
nosso cluster e como os usuários dessa aplicação a acessarão. 


Existem várias formas de disponibilizar a aplicação para que o 
usuário final consiga acessá-la em um cluster de AKS, por exemplo: 
através de um balanceador de carga (camada OSI 4) ou através de 
um Ingress Controller (camada OSI 7). Neste livro, vamos 
disponibilizar a aplicação por meio de um /ngress Controller com um 
serviço de NGINX atuando como um proxy reverso (camada OSI 7). 


Na imagem a seguir, demonstramos como os recursos do Azure e 
do Kubernetes estarão dispostos em nossa arquitetura inicial. 
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Figura 13.8: Arquitetura inicial da solugao com Azure Kubernetes Service. 


Para facilitar a criagao dos recursos do Kubernetes, primeiramente 
precisaremos criar UM namespace para isolar os recursos do NGINX 
de nossa aplicação dentro do Kubernetes. Para isso, utilizaremos a 
abordagem imperativa por meio do executável kubect1 . 


kubectl create ns ingress-controller 





Para que o NGINX funcione como um Ingress Controller acoplado 
ao Azure Kubernetes Service, precisaremos habilita-lo em nosso 
cluster. Para isso, instalaremos esse recurso com o auxílio da 


ferramenta Helm, que é um gerenciador de pacotes para o 
Kubernetes. 


# Adicionar o repositório do Ingress Controller do NGINX ao helm 
helm repo add 
ingress-NGINX https://kubernetes.github.io/ingress-NGINX 


# Instalar via helm o Ingress Controller do NGINX 
helm install NGINX-ingress ingress-NGINX/ingress-NGINX 


--namespace ingress-controller 

--set controller.replicaCount=2 

--set controller.nodeSelector."beta\ .kubernetes\ .io/os"=linux 

--set defaultBackend.nodeSelector."beta\.kubernetes\ .io/os"=linux 

--set 
controller.admissionWebhooks.patch.nodeSelector."beta\.kubernetes\ .io/ 
os"=linux 





Criando o arquivo de implantação dos recursos do Kubernetes 


Agora que temos a arquitetura da aplicação definida para o 
Kubernetes, podemos criar os recursos do Kubernetes com o estado 
desejado de nossa aplicação. 


Como boa prática devemos manter o controle do versionamento dos 
recursos do Kubernetes. Por isso, trabalharemos com a forma 
declarativa por meio do arquivo yami e adicionaremos esse arquivo 
ao nosso repositório git. 


Primeiramente precisamos isolar nossa aplicação em um namespace 
próprio. 


apiVersion: v1 


kind: Namespace 


metadata: 
name: eshoponweb 





Para garantir que os pods da aplicação sejam atualizados com o 
intuito de mitigar problemas de indisponibilidade, vamos criar o 
recurso de Deployment , que em seu valor padrão permite que 25% 
dos pods sejam atualizados de cada vez, no cenário em que novas 
versões da aplicação serão aplicadas em nosso cluster. 





apiVersion: apps/v1 
kind: Deployment 
metadata: 


name: web-deploy 
namespace: eshoponweb 
spec: 
selector: 
matchLabels: 
app: web 
replicas: 2 
template: 
metadata: 
labels: 
app: web 
spec: 
containers: 
- name: web 
image: creshoponweb.azurecr.io/eshoponweb-web:1.0 
ports: 
- containerPort: 80 
resources: 
limits: 
memory: "400M" 
requests: 
memory: "100M" 
env: 
- name: ASPNETCORE ENVIRONMENT 
value: Production 
- name: ASPNETCORE URLS 
value: http://+:80 
- name: APPCONFIG CONNECTIONSTRING 
value: "$((secrets.APPCONFIG CONNECTIONSTRING))" 
- name: AZURE CLIENT ID 
value: "$((secrets.AZURE CLIENT ID))" 
- name: AZURE CLIENT SECRET 
value: "$((secrets.AZURE CLIENT SECRET))" 
- name: AZURE TENANT ID 
value: "${{secrets.AZURE_TENANT_ID}}" 


apiVersion: apps/v1 
kind: Deployment 
metadata: 
name: publicapi-deploy 
namespace: eshoponweb 
spec: 
selector: 
matchLabels: 
app: publicapi 
replicas: 2 
template: 
metadata: 
labels: 
app: publicapi 
spec: 
containers: 
- name: publicapi 
image: creshoponweb.azurecr.io/eshoponweb-publicapi:1.0 
ports: 
- containerPort: 80 
resources: 
limits: 
memory: "200M" 
requests: 
memory: "80M" 
env: 
- name: ASPNETCORE ENVIRONMENT 
value: Production 
- name: ASPNETCORE URLS 
value: http://+:80 
- name: APPCONFIG CONNECTIONSTRING 
value: "$((secrets.APPCONFIG CONNECTIONSTRING))" 
- name: AZURE CLIENT ID 
value: "$((secrets.AZURE CLIENT ID))" 
- name: AZURE CLIENT SECRET 
value: "$((secrets.AZURE CLIENT SECRET))" 
- name: AZURE TENANT ID 
value: "${{secrets.AZURE_TENANT_ID}}" 


apiVersion: apps/v1 
kind: Deployment 
metadata: 
name: orderapi-deploy 
namespace: eshoponweb 
spec: 
selector: 
matchLabels: 
app: orderapi 
replicas: 2 
template: 
metadata: 
labels: 
app: orderapi 
spec: 
containers: 
- name: backend 
image: creshoponweb.azurecr.io/eshoponweb-orderapi:1.0 
ports: 
- containerPort: 80 
resources: 
limits: 
memory: "200M" 
requests: 
memory: "80M" 
env: 
- name: ASPNETCORE ENVIRONMENT 
value: Production 
- name: ASPNETCORE URLS 
value: http://+:80 
- name: APPCONFIG CONNECTIONSTRING 
value: "$((secrets.APPCONFIG CONNECTIONSTRING))" 
- name: AZURE CLIENT ID 
value: "$((secrets.AZURE CLIENT ID))" 
- name: AZURE CLIENT SECRET 
value: "$((secrets.AZURE CLIENT SECRET))" 
- name: AZURE TENANT ID 
value: "${{secrets.AZURE_TENANT_ID}}" 





E importante ressaltar que é extremamente recomendado definir 
limites para o consumo de recursos computacionais (CPU/memória) 
que o pod poderá utilizar. Caso os limites não sejam definidos, é 
possível que o pod consuma, por exemplo, toda a memória do nó e 
impacte todos os recursos disponíveis no nó em questão. 


Com o objetivo de permitir que as requisições cheguem até os pods 
do Web, criaremos o service do Web e consequentemente 
precisamos criar também o service do PublicApi e do OrderApi (que 
serão acionados pelo Web). 





apiVersion: v1 

kind: Service 

metadata: 
name: web-svc 
namespace: eshoponweb 


spec: 
selector: 
app: web 
ports: 
- protocol: TCP 
port: 80 
targetPort: 80 


apiVersion: v1 
kind: Service 
metadata: 
name: publicapi-svc 
namespace: eshoponweb 
spec: 
selector: 
app: publicapi 


ports: 
- protocol: TCP 
port: 80 


targetPort: 80 


apiVersion: v1 
kind: Service 
metadata: 
name: orderapi-svc 
namespace: eshoponweb 
spec: 
selector: 
app: orderapi 
ports: 


- protocol: TCP 
port: 80 
targetPort: 80 





Para finalizar, precisaremos criar as rotas dentro do recurso de 
ingress , que agira como nossa porta de entrada do cluster e 
redirecionará as requisições para o serviço do Web (através do 
caminho / )e para a API pública (através do caminho api), para 
permitir que o projeto em Blazor a acesse. 


apiVersion: networking.k8s.io/vibeta1 
kind: Ingress 
metadata: 
name: eshoponweb-ingress 
namespace: eshoponweb 
annotations: 
kubernetes.io/ingress.class: NGINX 
spec: 
rules: 
- http: 
paths: 
- path: / 
backend: 
serviceName: web-svc 
servicePort: 80 


- path: /api 
backend: 
serviceName: publicapi-svc 


servicePort: 80 





Escalando os pods 


Com a finalidade de escalar os pods a medida que a aplicação 
necessita, vamos adotar o uso do recurso do Kubernetes chamado 
de Horizontal Pod Autoscaler (HPA). Esse recurso permite 


especificar qual sera a métrica utilizada (CPU e/ou memória) e qual 
O limite mínimo e máximo de pods configurados para a 
escalabilidade automática. 


Em nosso exemplo, adotaremos somente a configuração de 
utilização de CPU em 60%, ou seja, caso a média de consumo de 
CPU dos pods atinja mais que 60%, um novo pod será criado 
(respeitando o número máximo de réplicas). 


apiVersion: autoscaling/v1 
kind: HorizontalPodAutoscaler 
metadata: 

name: web-hpa 

namespace: eshoponweb 


spec: 
scaleTargetRef: 
apiVersion: apps/v1 
kind: Deployment 
name: web-deploy 
minReplicas: 2 
maxReplicas: 4 


targetCPUUtilizationPercentage: 


apiVersion: autoscaling/v1 
kind: HorizontalPodAutoscaler 
metadata: 
name: publicapi-hpa 
namespace: eshoponweb 
spec: 
scaleTargetRef: 
apiVersion: apps/v1 
kind: Deployment 
name: publicapi-deploy 
minReplicas: 2 
maxReplicas: 4 


targetCPUUtilizationPercentage: 


apiVersion: autoscaling/v1 
kind: HorizontalPodAutoscaler 
metadata: 
name: orderapi-hpa 
namespace: eshoponweb 
spec: 
scaleTargetRef: 





60 


60 


apiVersion: apps/v1 

kind: Deployment 

name: orderapi-deploy 
minReplicas: 2 
maxReplicas: 4 
targetCPUUtilizationPercentage: 60 





Alterando o processo de entrega continua 


Como a aplicagao em questao agora contempla algumas imagens 
de contéiner e toda a configuração de como ela deve se comportar 
no cluster, informada no yami criado anteriormente, precisaremos 
apenas aplicar esse arquivo no cluster do AKS para que ele consiga 
provisionar OS recursos. 


Como neste capítulo foi introduzida a centralização das 
configurações no Azure App Configuration, faz-se necessária a 
configuração dos segredos AaPPCONFIG CONNECTIONSTRING , 

AZURE CLIENT ID, AZURE CLIENT SECRET @ AZURE TENANT ID NO GitHub, 
com a finalidade de realizar a substituição dos respectivos valores 
no arquivo yamı . Com isso, teremos nossos segredos cadastrados 
conforme imagem a seguir. 


Repository secrets 


= 


ACR_PASSWORD 


ACR_SERVER 


ACR_USERNAME 


APPCONFIG CONNECTIONSTRING 


AZURE CLIENT ID 


AZURE CLIENT SECRET 


AZURE CREDENTIALS 


AZURE_TENANT ID 


STORAGE ACCOUNT KEY 


STORAGE ACCOUNT NAME 


Figura 13.9: Secrets no GitHub. 


Todo aquele processo de entrega continua, que foi criado no 
decorrer deste livro, se resumira apenas em: 


e Criar um contexto de conexão ao cluster de AKS. 
e Efetuar trocas de valores de variáveis de ambiente. 
e Aplicar o nosso arquivo yamı no cluster. 


A seguir, temos o código que demonstra esses passos. 





- name: Login AKS Cluster 

uses: Azure/aks-set-context@v1 

with: 
creds: "${{ secrets.AZURE CREDENTIALS }}" 
cluster-name: aks-cluster 
resource-group: rg-eshoponweb-cloud 

id: login 


name: YAML Transform - APPCONFIG CONNECTIONSTRING 
uses: jwsi/secret-parser@v1 
with: 
filename: src/PaaSDeploy/eshoponweb. yaml 
secret-name: APPCONFIG CONNECTIONSTRING 
secret-value: ${{ secrets.APPCONFIG CONNECTIONSTRING }} 


name: YAML Transform - AZURE_CLIENT_ID 

uses: jwsi/secret-parser@v1 

with: 
filename: src/PaaSDeploy/eshoponweb. yaml 
secret-name: AZURE CLIENT ID 
secret-value: ${{ secrets.AZURE CLIENT ID }} 


name: YAML Transform - AZURE CLIENT SECRET 

uses: jwsi/secret-parser@v1 

with: 
filename: src/PaaSDeploy/eshoponweb.yaml 
secret-name: AZURE CLIENT SECRET 
secret-value: ${{ secrets.AZURE CLIENT SECRET }} 


name: YAML Transform - AZURE TENANT ID 

uses: jwsi/secret-parser@v1 

with: 
filename: src/PaaSDeploy/eshoponweb.yaml 
secret-name: AZURE TENANT ID 
secret-value: ${{ secrets.AZURE TENANT ID }} 


name: Kubernetes Deploy 
uses: Azure/k8s-deploy@v1 
with: 


namespace: "eshoponweb" 

manifests: | 

src/PaaSDeploy/eshoponweb. yaml 

images: | 

${{secrets.ACR_SERVER}}/eshoponweb-web: ${{github.sha}} 
${{secrets.ACR_SERVER}}/eshoponweb-publicapi:${{github.sha}} 
${{secrets.ACR_SERVER}}/eshoponweb-orderapi:${{github.sha}} 


NOTA 


O arquivo completo (eshoponweb-cd.yml) pode ser encontrado 
em nosso repositorio oficial. 





13.3 Monitoração dos recursos do cluster de AKS 


Assim como detalhado no capítulo 3, a monitoração é um ponto 
bastante importante para qualquer ambiente e aplicação seja on- 
premises ou em nuvem. 


Para termos visibilidade de como os recursos dentro do cluster 
estão se comportando e o quanto de recurso computacional está 
sendo utilizado por cada um, recomenda-se habilitar o 
monitoramento desses recursos no cluster do AKS por meio do 
Azure Monitor. 


Para habilitar a monitoração, será necessário criar um espaço onde 
as informações serão salvas por um período padrão de 30 dias 
chamado de workspace. 


O workspace é criado através do comando: 


az monitor log-analytics workspace create 
-g rg-eshoponweb-cloud 


-n log-eshoponweb-aks-cluster 





No ambiente do AKS, assim como na monitoração de máquinas 
virtuais em modo laaS, a monitoração é realizada por agentes que 
são instalados nas máquinas, e as informações são enviadas de 
tempos em tempos para o workspace. 


Para monitorar o que acontece dentro do cluster do AKS, como 
informações de saída ( stdout ) de contêineres, consumo de memória 
e CPU, quantidade de restarts que um pod sofreu, entre outras, o 
serviço de monitoração instalará um daemon set, chamado de oms- 
agent, instalado como um serviço em cada máquina do cluster para 
que esses dados sejam coletados e enviados ao workspace. 


Para habilitar a monitoração no cluster do AKS, execute o comando 
a seguir: 


# Resgatar o workspace-resource-id 
$WKS_ID = (az monitor log-analytics workspace show 
-n log-eshoponweb-aks-cluster 
-g rg-eshoponweb-cloud 
--query id 
-o tsv) 


# Habilitar monitoração no cluster do AKS 
az aks enable-addons 


monitoring 


aks-cluster 
rg-eshoponweb-cloud 
--workspace-resource-id $WKS ID 





Após habilitada a monitoração, as informações serão coletadas e 
adicionadas ao workspace informado. Você poderá visualizar os 
dados da monitoração através do menu Insights, que está disponível 
dentro do recurso do Azure Kubernetes Services. 


me > Resource groups > rg-eshoponweb-cloud > aks-cluster 


@ aks-cluster | Insights 
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Figura 13.10: Menu Insights do recurso de AKS. 


13.4 Infraestrutura como código 


A infraestrutura como código, em inglês /nfrastructure as Code 
(laC), permite que, por meio do código, o time provisione sua 
infraestrutura automaticamente, sem a necessidade de criar os 
recursos manualmente, o que facilita o gerenciamento da 
infraestrutura em todos os ambientes (desenvolvimento, 
homologação, produção etc.). 


Como o mercado de tecnologia é bastante dinâmico e podemos ter 
mudanças tanto na aplicação como na infraestrutura, faz-se 


necessária a criação dessa automação para todos os recursos que 
envolvem a aplicação. 


Para adotar essa prática, vamos exemplificar a automação da 
criação da infraestrutura da aplicação em que estamos trabalhando 
utilizando uma ferramenta de mercado chamada Terraform, que 
permite criar os recursos de infraestrutura através de uma 
linguagem chamada HCL (HashiCorp Configuration Language). Por 
meio dessa linguagem, definiremos as especificações para os 
recursos que criaremos no nosso ambiente no Azure. 


Antes de criar, vamos relembrar os recursos do Azure que criamos 
neste capítulo para provisioná-los através do Terraform. 


e Resource Group. 

e Azure Key Vault. 

Azure App Configuration. 

e Azure Container Registry. 
e Log Analytics. 

Azure Kubernetes Service. 


Criação do arquivo e primeiras definições 


Primeiramente vamos criar um arquivo chamado main.tf que será 
utilizado para adicionarmos o código que provisionará nossa 
infraestrutura no Azure. 


Para que o Terraform entenda que os recursos criados são do 
Azure, precisamos especificar qual provider deve ser utilizado. Para 
isso, definimos a seguinte instrução: 


provider "“azurerm" { 
features {} 


} 





Com o objetivo de facilitar e deixar nosso arquivo parametrizavel, 
vamos criar a variável location , que define em qual região os 
recursos do Azure serão criados. 


variable "location" { 
default = "brazilsouth" 





Nos próximos tópicos, criaremos as especificações dos recursos 
contendo os mesmos parâmetros que utilizamos através do Azure 
CLI. 


Criando o grupo de recursos 


Para criar o grupo de recursos, utilizaremos o recurso 

azurerm resource group do Terraform e informaremos um alias para 
ele (rg). Em sua parametrização, precisaremos informar os 
parâmetros obrigatórios: 


name: nome do grupo de recurso. location: região do Azure em que 
o recurso será provisionado. Neste caso, utilizaremos a variável que 
criamos anteriormente. 


resource "azurerm resource group” 
name = "rg-eshoponweb-cloud" 
location = var.location 


rg" { 





Criando o Azure Key Vault 


Especificamente para o Azure Key Vault, precisaremos: 


e De uma variável que servirá como parâmetro, com o objetivo de 
armazenar o object id do Service Principal, criado anteriormente 
neste capítulo (AzureKeyVault-AKS-eShopOnWeb). 
Relembrando: esse Service Principal será utilizado pela 
aplicação para que ela consiga ter acesso às informações 
armazenadas no Key Vault. 


e Adicionar uma configuração (data azurerm client config) com o 
objetivo de capturar automaticamente o tenant id da 
subscription do Azure. 


Com isso, temos o seguinte código: 


variable "keyvault-serviceprincipal” { 
description = "Informe o ID do SP-RBAC para o Azure Key Vault" 
} 


data "azurerm_client_config" "current" {} 
resource "azurerm_key_vault" "keyvault" { 
name = "keyvault-eshoponweb" 
location var.location 
resource_group_name = azurerm_resource_group.rg.name 
tenant_id = data.azurerm_client_config.current.tenant_id 
sku_name "standard" 
soft delete enabled true 
soft delete retention days 99 


access policy { 
tenant_id = data.azurerm_client_config.current.tenant_id 


object_id = var.keyvault-serviceprincipal 


key_permissions = [ 
"Create", "Decrypt", "Delete", "Encrypt", 
"Get", "List", "UnwrapKey", "WrapKey" 


secret_permissions = [ 
"Delete", "Get", “List”, "Set" 





Criando o Azure App Configuration 


De agora em diante, todos os recursos seguem a mesma linha de 

raciocínio. Precisamos sempre informar qual o nome do recurso do 
Terraform a ser utilizado, um alias e também definir os parâmetros 

obrigatórios de cada um dos recursos. 


appconfig" { 


resource "azurerm_app_configuration 


name "appconfig-eshoponweb" 
resource_group_name azurerm_resource_group.rg.name 
location var. location 

sku = "standard" 


resource "azurerm_container_registry" "acr" { 
name "creshoponweb" 
resource_group_name azurerm_resource_group.rg.name 
location var.location 
sku "Basic" 
admin_enabled true 





Criando o Log Analytics 


resource "azurerm_log analytics workspace" "log" { 
name = "log-eshoponweb-aks-cluster" 
location var. location 
resource group name = azurerm_resource_group.rg.name 
sku "pergb2018" 


resource "azurerm_log analytics solution 
solution_name = "Containers" 


solution" { 


workspace resource id= azurerm log analytics workspace.log.id 
workspace name azurerm log analytics workspace. log.name 
location var. location 


resource group name azurerm resource group.rg.name 


plan { 
publisher = "Microsoft" 
product = "OMSGallery/Containers" 





Criando o Azure Kubernetes Service 


resource “azurerm kubernetes cluster 


name 


location = var.location 


"aks-cluster' 





"aks-cluster" { 


resource group name = azurerm_resource_group.rg.name 
dns prefix = "aks-cluster-eshoponweb" 


role based access control ( 
enabled = true 


} 

default_node_pool { 
name = "nodeapp" 
node_count = 2 


enable_auto_scaling = true 


vm_size = "Standard F4s v2" 
type = "VirtualMachineScaleSets" 
min_count = 2 
max count =5 

} 

network_profile { 
network plugin = "kubenet" 
load_balancer_sku = "standard" 


outbound type = "loadBalancer' 


} 


identity { 
type = "SystemAssigned" 
} 


addon_profile { 
aci_connector_linux { 
enabled = false 


azure_policy { 
enabled = false 


http_application_routing { 
enabled = false 


kube_dashboard { 
enabled = false 


oms_agent { 
enabled = true 
log analytics workspace id = 
azurerm log analytics workspace.log.id 


} 

} 

} 

resource "azurerm_kubernetes_cluster_node_pool" "nodesystem" { 
name = "nodesystem" 
kubernetes cluster id = azurerm kubernetes cluster.aks-cluster.id 
vm size = "Standard DS2 v2" 
enable auto scaling = false 
node count = 2 
mode = "System" 

} 

resource "azurerm_role_assignment" "aks-acr" { 
scope = azurerm_container_registry.acr.id 
role definition name = "AcrPull" 


principal id = azurerm kubernetes cluster.aks- 
cluster.kubelet identity[0].object id 


} 





Arquivo main.tf 


Com todos os recursos definidos, temos o seguinte conteúdo do 
nosso arquivo main.tf. 





provider "“azurerm" { 
features {} 


variable "location" { 
default = "brazilsouth" 


variable "keyvault-serviceprincipal” { 
description = "Informe o ID para o Azure Key Vault" 


} 


data “azurerm client config" "current" {} 

# Resource Group 

resource "azurerm_resource_group 
name = "rg-eshoponweb-cloud" 


rg" { 


location = var.location 


# Azure Key Vault 
resource "azurerm_key_vault" "keyvault" { 


name = "keyvault-eshoponweb" 

location = var.location 

resource_group_name = azurerm_resource_group.rg.name 
tenant_id = data.azurerm_client_config.current.tenant_id 
sku_name = "standard" 

soft delete enabled = true 

soft delete retention days = 90 


access policy { 
tenant_id = data.azurerm_client_config.current.tenant_id 
object_id = var.keyvault-serviceprincipal 


key_permissions = [ 
"Create", "Decrypt", "Delete", "Encrypt", 
"Get", "List", "UnwrapKey", "WrapKey" 


secret_permissions = [ 
"Delete", "Get", "List", "Set" 


# Azure App Configuration 
resource "azurerm_app_configuration" "appconfig" { 


name = "appconfig-eshoponweb" 
resource_group_name = azurerm_resource_group.rg.name 
location = var.location 

sku = "standard" 


# Azure Container Registry 


resource "azurerm_container_registry" "acr" { 
name = "creshoponweb" 
resource_group_name = azurerm_resource_group.rg.name 
location = var.location 
sku = "Basic" 
admin_enabled = true 


# Log Analytics - Workspace 
resource "azurerm_log analytics workspace" "log" { 


name = "log-eshoponweb-aks-cluster" 
location = var.location 
resource_group_name = azurerm_resource_group.rg.name 
sku = "pergb2018" 


# Log Analytics - Solution 
resource "azurerm_log analytics solution" "solution" { 


solution_name = "Containers" 

workspace resource id= azurerm log analytics workspace.log.id 
workspace name = azurerm log analytics workspace. log.name 
location = var.location 

resource group name = azurerm resource group.rg.name 

plan { 


publisher = "Microsoft" 


product = "OMSGallery/Containers" 


# Azure Kubernetes Service 


resource "azurerm kubernetes cluster" "aks-cluster" { 


name = "aks-cluster" 

location = var.location 

resource group name = azurerm_resource_group.rg.name 
dns prefix = "aks-cluster-eshoponweb" 


role based access control ( 
enabled = true 


} 

default_node_pool { 
name = "nodeapp" 
node_count = 2 


enable_auto_scaling = true 


vm_size = "Standard F4s v2" 
type = "VirtualMachineScaleSets" 
min count =2 
max count =5 

} 

network_profile { 
network plugin = "kubenet" 
load_balancer_sku = "standard" 
outbound_type = "loadBalancer" 

} 

identity { 
type = "SystemAssigned" 

} 


addon_profile { 
aci_connector_linux { 
enabled = false 


azure_policy { 


enabled = false 


http_application_routing { 
enabled = false 


kube_dashboard { 
enabled = false 


oms_agent { 
enabled = true 
log analytics workspace id = 
azurerm log analytics workspace.log.id 


# AKS - System NodePool 
resource "“azurerm kubernetes cluster node pool” "nodesystem" { 


name = "nodesystem" 

kubernetes cluster id = azurerm kubernetes cluster.aks-cluster.id 
vm size = "Standard DS2 v2" 

enable auto scaling = false 

node count =2 

mode = "System" 


# Azure Container Registry - Attach AKS 
resource "azurerm_role_assignment" "aks-acr" { 


scope = azurerm_container_registry.acr.id 

role definition name = "AcrPull" 

principal id = azurerm kubernetes cluster.aks- 
cluster.kubelet identity[0].object id 


} 





Armazenamento de estado 


Como você já pode saber, o Terraform contempla um mecanismo de 
controle de estado. Esse controle nada mais é que o 
armazenamento do último estado dos recursos de infraestrutura 
referente à última execução. Ele precisa desse controle de estado 
para ter conhecimento de quais recursos devem ser alterados, 
criados ou excluídos. 


Como vamos incluir a execução do arquivo do Terraform em nosso 
workflow do GitHub Action, precisaremos utilizar um local único e 
seguro para o armazenamento do arquivo de estado. 


Para isso, utilizaremos nosso Storage Account steshopdata, que 
está localizado em outro grupo de recursos (rg-eshoponweb). 
Precisaremos apenas criar um novo contêiner nesse Storage 
Account, que, para nosso exemplo, chamaremos de ffstate. 


Após criado o contêiner, precisamos definir essas informações em 
nosso arquivo do Terraform por meio da seguinte instrução: 


terraform { 
backend "azurerm" { 
resource_group_name "rg-eshoponweb" 
storage account name = "steshopdata” 


container name = "tfstate" 
key "prod.terraform.tfstate" 





Importando os recursos existentes 


Tendo em vista que nosso arquivo de controle de estado está 
armazenado no Storage Account e que já havíamos criado os 
recursos no Azure por meio do Azure CLI, precisaremos realizar a 
importação desses recursos com o objetivo de atualizar nosso 
arquivo de estado. 


O Terraform possui um comando chamado terraform import , que 
realiza essa importação. Precisamos apenas informar que tipo de 
recurso será importado e qual seu Resource ID, conforme 
demonstrado a seguir. 


# Importação do Resource Group 
terraform import "azurerm_resource_group.rg" 
/subscriptions/<SUBSCRIPTION_ID>/resourceGroups/rg-eshoponweb-cloud 


# Importação do Azure Key Vault 

terraform import "azurerm_key_vault.keyvault" 
/subscriptions/<SUBSCRIPTION_ID>/resourceGroups/rg-eshoponweb- 
cloud/providers/Microsoft.KeyVault/vaults/keyvault-eshoponweb 


# Importação do Azure App Configuration 

terraform import "azurerm_app_configuration.appconfig" 
/subscriptions/<SUBSCRIPTION_ID>/resourceGroups/rg-eshoponweb- 
cloud/providers/Microsoft.AppConfiguration/configurationStores/> 
appconfig-eshoponweb 


# Importação do Azure Container Registry 

terraform import "azurerm container registry.acr" 
/subscriptions/<SUBSCRIPTION ID>/resourceGroups/rg-eshoponweb- 
cloud/providers/Microsoft.ContainerRegistry/registries/creshoponweb 


# Importação do Log Analytics 

terraform import "azurerm_log analytics_workspace.1log" 
/subscriptions/<SUBSCRIPTION_ID>/resourcegroups/rg-eshoponweb- 
cloud/providers/microsoft.operationalinsights/workspaces/> log- 
eshoponweb-aks-cluster 


# Importação do Azure Kubernetes Service 

terraform import "azurerm kubernetes cluster.aks-cluster" 
/subscriptions/<SUBSCRIPTION ID>/resourcegroups/rg-eshoponweb- 
cloud/providers/Microsoft.ContainerService/managedClusters/> aks- 
cluster 





Apos os recursos terem sido importados com sucesso, realize as 
ações do Terraform para efetuar a sincronização do arquivo main.tf 
e do estado atual do Terraform, que está localizado no Storage 
Account, por meio dos seguintes comandos. 


terraform init 


terraform plan 


terraform apply 





Alterando o processo de entrega contínua 


Com o arquivo main.tf gerado, podemos guardar suas versões 
juntamente com nossa aplicação e, a cada ação de modificação 
feita nos recursos, os arquivos do Terraform devem ser atualizados 
para refletir o novo estado. 


Com o intuito de automatizar o processo de provisionamento do 
ambiente contendo a infraestrutura necessária para a nossa 
aplicação, conforme definido no arquivo do Terraform, vamos alterar 
o processo de entrega contínua incluindo a execução do Terraform 
pelo GitHub Action. 


Antes de tudo, precisaremos criar um Service Principal com 
permissão de manipulação dos recursos da subscription no Azure 
por meio da seguinte linha de comando do Azure CLI. 


az ad sp create-for-rbac 
-n "Terraform-eShopOnWeb" 


--role="Contributor" 
--scopes="/subscriptions/<SUBSCRIPTION_ID>" 





Apos criado, utilize os valores retornados na area de segredos no 
GitHub conforme segue. 


e Segredo: ARM CLIENT ID 
o Valor: Client id do Service Principal Terraform-eshoponweb 
e Segredo: ARM CLIENT SECRET 
o Valor: Secret do Service Principal terraform-eShopOnwWeb 
e Segredo: ARM SUBSCRIPTION ID 
o Valor: ID da subscription 
e Segredo: KEY VAULT SERVICE PRINCIPAL ID 
o Valor: Client id do Service Principal que criamos 
anteriormente com o nome de AzureKeyVault-AKS-eShopOnWeb 


Com os segredos criados, altere o arquivo eshoponweb-cd.yml, 
informando as variáveis de ambiente no workflow conforme exemplo 
a seguir. 


env: 
ARM CLIENT ID: ${{ secrets.ARM CLIENT ID }} 
ARM CLIENT SECRET: ${{ secrets.ARM CLIENT SECRET }} 


ARM SUBSCRIPTION ID: ${{ secrets.ARM SUBSCRIPTION ID }} 
ARM TENANT ID: ${{ secrets.AZURE TENANT ID }} 





Neste mesmo arquivo, altere o fluxo da entrega contínua, incluindo 
os passos do Terraform após as execuções dos comandos do dotnet 
publish e antes da criação dos contêineres. 


: Setup Terraform 
: hashicorp/setup-terraform@v1 


: Terraform Init 
: terraform init 


name: Terraform Plan 
run: terraform plan -var="keyvault-serviceprincipal=${{ 
secrets.KEY VAULT SERVICE PRINCIPAL ID }}" 


- name: Terraform Apply 


run: terraform apply -var="keyvault-serviceprincipal=$(( 
secrets.KEY VAULT SERVICE PRINCIPAL ID }}" -auto-approve 


NOTA 


O arquivo completo ( eshoponweb-cd.ym1 ) pode ser encontrado em 
nosso repositório oficial. 





Com isso, finalizamos o processo de transformação de uma 
aplicação de modelo laaS em uma de modelo Paas. 


13.5 Resumo 


Neste capítulo, abordamos o assunto de orquestração de contêiner, 
no qual: 


e Aprendemos o que é o Kubernetes e como podemos executar 
os contêineres em um ambiente de Azure Kubernetes Service 
habilitando escalabilidade e monitoração; 

e Entendemos o que é infraestrutura como código e como gerar 
nossos recursos do Azure a partir do Terraform; 


e E, por fim, alteramos todo o processo de CI/CD contemplando 
este novo cenário. 


CAPITULO 14 
Identidade e segurança 


Escrito por Cleber Dantas e Marcelo Tokunaga. 


Neste capítulo, vamos abordar os seguintes assuntos: 


e O que é Identidade como Serviço. 


e Diferenças entre Azure AD e Azure AD B2C. 
e Os protocolos OAuth 2.0 e OpenID Connect. 
e Como implementar o Azure AD B2C. 





Vimos anteriormente como trazer nossa aplicação para a nuvem e, 
aos poucos, como reestruturá-la para que possamos nos beneficiar 
de alguns conceitos como gestão de código-fonte, monitoração, 
teste e conteinerização. 


Neste capítulo, abordaremos algumas formas de manter sua 
aplicação mais segura utilizando serviços de gestão de identidade e 
proteção disponíveis no Azure. 


14.1 O que é Identidade como Serviço (IDaaS)? 


Identidade como Serviço é uma forma de disponibilizar aos 
desenvolvedores a possibilidade de utilizar provedores de 
identidade de uma maneira fácil e rápida, abstraindo todas as 
complexidades relativas à criação e manutenção das identidades. 


Conceitos básicos 


Antes de chegarmos ao conceito de serviço, vamos entender alguns 
conceitos básicos, como identidade, autenticação e autorização. 


Identidade 


"Identidade é o conjunto de características próprias e exclusivas 
com as quais se podem diferenciar pessoas, animais, plantas e 

objetos inanimados uns dos outros, quer diante do conjunto das 
diversidades, quer ante seus semelhantes.” - Wikipédia 


Mas e no mundo dos softwares? Quando discutimos identidade, do 
que exatamente estamos falando? 


A identidade no mundo dos softwares, de modo simplificado, pode 
ser definida como a identificação de um usuário, por exemplo, sua 
conta de login com alguns serviços de redes sociais. Esse conceito 
também pode ser aplicado a outros componentes, como um 
sistema. 


Podemos dizer que um determinado sistema tem uma identidade e, 
dessa forma, podemos utilizar a identidade de um sistema para que 
ele tenha acesso a um conjunto de dados específicos, por exemplo, 
em um cenário de integração Business to Business (B2B). 


Em linhas gerais, podemos então afirmar que identidade é uma 
identificação do usuário/sistema. 


Autenticação 


Mas como podemos saber se o usuário é realmente quem ele diz 
ser? Para garantir essa informação, realizamos uma etapa chamada 
autenticação. 


Na autenticação, o usuário simplesmente prova quem ele realmente 
é. Ele pode fazer isso informando uma senha, apresentando uma 
chave específica ou utilizando meios mais complexos, como o 
conceito de autenticação multifator. 


Na autenticação multifator, sao utilizados pelo menos dois meios 
diferentes para que o usuário "prove" quem ele é. Por exemplo, o 
usuário se autentica provendo seu usuário (geralmente um 
endereço de e-mail) e uma senha. Ao verificar que a senha está 
correta, o sistema então pede um segundo fator de autenticação 
que pode ser o envio de um código específico para um dispositivo 
pessoal ou mesmo uma prova biométrica, como a verificação de sua 
impressão digital. 


Autorização 


Após sabermos que o usuário é quem ele realmente diz ser, como 
podemos saber o que o usuário de fato pode fazer no sistema? Ou 
seja, o que o usuário está autorizado a realizar no sistema? Esse 
controle de autorização pode ser feito, por exemplo, por meio do uso 
de papéis. 


Imagine que temos alguns papéis na utilização do sistema: o 
vendedor, o usuário do caixa e um gerente. Cada um terá acesso a 
uma parte diferente da aplicação de acordo com a função que 
exerce na empresa. 


Para podermos efetuar esse controle, a ideia é criar papéis que 
representem essas funções no sistema e associar usuários a eles. 
Isso pode ser feito, por exemplo, durante o cadastro dos usuários. 


Provedores de identidade 


Agora que já sabemos os conceitos básicos, o que seria um 
provedor de identidade” 


Um provedor de identidade nada mais é do que um sistema que 
atesta a veracidade das identidades para os provedores de serviço. 


Um provedor de identidade realiza as seguintes funções: 


e Gestão de usuário (cadastro, alteração, exclusão). 
e Administração da senha. 


e Processo de autenticação. 
Formas de implementação de um provedor de identidade 


Conforme dito anteriormente, um provedor de identidade 
essencialmente é um sistema que realiza a gestão dos usuários 
bem como sua forma de autenticação. E é exatamente nessa forma 
de autenticação que se encontra a parte mais sensível, pois é nesse 
ponto que serão realizadas as integrações com os provedores de 
serviço que confiarão na sua identidade. 


Por conta dessa complexidade, ao longo do tempo, tivemos 
algumas versões e formas de implementação. Nesta seção, vamos 
destacar os três processos mais utilizados em conjunto com o 
ASP.NET. 


ASP.NET Membership 


O ASP.NET Membership surgiu com o ASP.NET 2.0 em 2005. Ele 
era um sistema de gestão de identidades todo baseado em bancos 
de dados relacionais e inicialmente foi desenhado para utilizar uma 
base de dados SQL Server, no entanto isso podia ser alterado para 
trabalhar com outras bases, bastando para isso customizar seu 
Provider. 


Como principais características, o ASP.NET Membership permitia: 


e Integrar com Forms Authentication. 
e Utilizar uma base de dados relacional no SQL Server para 
guardar dados de usuario, senha e perfis. 


No entanto, suas limitações faziam com que ele não fosse o ideal 
para se utilizar com bases de dados que não fossem relacionais, e 
nem permitiam uma forma mais ampla de integração com outras 
formas de autenticação. 


ASP.NET Identity 


O ASP.NET Identity é uma evolução do ASP.NET Membership. 
Baseado em feedbacks de usuários e da comunidade, a Microsoft 
evoluiu a ferramenta adicionando funcionalidades para que ela se 
adequasse às práticas comuns de mercado. 


Destacamos essas funcionalidades na lista a seguir: 


e Sistema único de gestão de identidade para várias tecnologias, 
como ASP.NET MVC, Web Forms, Web Pages, Web API e 
SignalR. 

e A ferramenta possui agora um sistema de persistência 
desacoplado que faz uso da tecnologia Entity Framework Code 
First, o que possibilita conexão com vários métodos de 
persistência, incluindo bancos de dados NoSQL ou plataformas 
como o Sharepoint. 

e Possibilita também que o serviço possa controlar variáveis 
relacionadas ao usuário, como data de nascimento, 
independente do provedor de identidade. 

e Permite integração com testes de unidade. 

e Permite a utilização de uma forma de autorização baseada em 
papéis, por exemplo, pode-se criar papéis como Administrador, 
Desenvolvedor. 

e Suporta autenticação baseada em claims. 

e Integração com provedores de identidade social, como 
Microsoft Account, Facebook, Twitter, Google e outros 
compatíveis. 

e Possui instalação baseada em pacotes Nuget. 

e Permite integração com o padrão OWIN (Open Web Interface 
for .NET). 


Utilizando o ASP.NET Identity, você consegue integrar com diversos 
provedores de identidade ou até mesmo utilizar bases de usuários 
existentes em suas aplicações legadas, modernizando sua 
aplicação e possibilitando uma evolução gradual. 


Identity Server 4 


O propósito principal do Identity Server 4 é a criação de provedores 
de identidade. O Identity Server 4 é o que chamamos de 
middleware, ou seja, uma camada adicional que pode ser 
adicionada ao seu provedor de identidade para que ele se torne 
compatível com as principais práticas de mercado, como destacado 
a seguir: 


e Oferece o serviço de Authentication as a Service, pois é uma 
implementação certificada do protocolo OpenID Connect. 

e Permite integrações do tipo Single Sign-On/Sign-Out. 

Oferece compatibilidade com controle de acesso a APIs. 

Permite integração de federação com provedores externos, 

como Azure Active Directory, Google e Facebook. 


14.2 Diferenças entre Azure AD e Azure AD B2C 


Azure Active Directory ou simplesmente Azure AD é a oferta de 
IDaas (Identity as a Service) da Microsoft. Seu principal objetivo é 
prover capacidades de autenticação e autorização para aplicações 
baseadas em nuvem (aplicações SaasS, Software as a Service). 
Quais as diferenças entre Azure AD, Azure AD B2B e Azure AD 
B2C? São serviços diferentes entre si? São funcionalidades 
existentes dentro do Azure AD? Vamos responder a essas 
perguntas nesta seção. 


Azure AD, Azure AD B2B e Azure AD B2C 


O principal objetivo do Azure AD é prover serviços de identidade 
com foco em nuvem para organizações. A ideia é permitir que as 
empresas aumentem o seu alcance para além de seus escritórios 


fisicos, e que seus colaboradores tenham acesso a recursos 
presentes localmente ou na nuvem de modo transparente e com 
total seguranga. Funcionalidades como acesso condicional, 
proteção de identidade, autenticação multifator, gerenciamento de 
dispositivos, entre outros estão presentes nessa solução. 


Desenvolvedores podem criar aplicações e protegê-las com o Azure 
AD, sejam do tipo single-tenant, aplicações desenvolvidas para uma 
organização específica, ou multi-tenant, aplicações que 
organizações diferentes que utilizem Azure AD podem aproveitar. 


O Office 365 e o próprio Azure são exemplos de aplicações multi- 
tenant, já que várias organizações diferentes podem utilizá-las. 


Azure 
Active Directory, 





On premise apps 





LOB Apps SaaS Apps 


Figura 14.1: Possibilidades com Azure AD. 


Azure AD B2B (business-to-business) não é um serviço apartado 
do Azure AD e sim uma de suas funcionalidades. Seu objetivo é 
permitir que uma organização convide membros de outra 
organização para colaboração em algum recurso que precise ser 
compartilhado. 


Com o Azure AD B2B, as organizações não precisam mais criar, por 
exemplo, um usuário temporário dentro de seu diretório para permitir 


acesso de um terceiro. Também não precisam se preocupar com a 
remoção desse usuário do diretório quando o acesso dele não fizer 
mais sentido. O acesso ao recurso se dará por meio do usuário já 
existente na outra organização, facilitando bastante a criação de 
ambientes colaborativos entre parceiros de negócios. 
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Figura 14.2: Colaboração B2B. 


Azure AD B2C (business-to-consumer) é um serviço 
completamente separado do Azure AD (são necessários tenants 
separados) com o objetivo de proteger aplicações voltadas para o 
cliente final de sua empresa, por exemplo, e-commerce, 
atendimento ao cliente, entre outros. 


Os usuários dessas aplicações não fazem parte da sua 
organização, portanto não faria sentido que eles tivessem usuários 
dentro do seu Azure AD corporativo. A ideia é ter um tenant 
separado para abrigar esses usuários. 
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Figura 14.3: Azure AD B2C. 


IDs sociais, email ou contas locais 









Os fluxos de cadastro, edição de perfil e login sao totalmente 
customizaveis com o Azure AD B2C, além disso você pode associar 
diferentes provedores sociais à solução, como Twitter, Facebook, 
LinkedIn, entre outros. Dessa forma, os usuários podem escolher se 
conectarão suas contas existentes a sua aplicação ou criarão uma 
conta do zero (conta local). 
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Figura 14.4: Tela de login de exemplo com Azure AD B2C. 


Também é possível conectar contas corporativas ao Azure AD B2C. 
Além de dar a possibilidade de usuários externos acessarem a 
aplicação com suas contas locais ou sociais, pode-se permitir que 
usuários de uma determinada organização também se conectem a 
tal aplicação com suas atuais credenciais corporativas. 


Um paralelo interessante para avaliarmos se faz sentido para uma 
aplicação a utilização do Azure AD B2C é verificarmos se soluções, 


como ASP.NET Membership, ASP.NET Identity, Identity Server 4 ou 
até mesmo uma tabela de usuarios no banco de dados com 
informações de usuário e senha, se aplicam ao cenário em questão. 


Se soluções como as anteriores fizerem sentido para resolver os 
problemas de autenticação/autorização de sua aplicação, o Azure 
AD B2C é uma moderna e excelente alternativa. 


14.3 Os protocolos OAuth 2.0 e OpenID Connect 


Autorização e autenticação são aspectos fundamentais para 
qualquer sistema de segurança. Como vimos anteriormente, o tema 
Identidade como Serviço (IDaaS) veio para ficar, e como tais 
serviços são baseados em nuvem, protocolos mais amigáveis para 
esse ambiente precisaram ser criados. Estamos falando de OAuth 
2.0 e OpenID Connect. São eles os protocolos que nos ajudarão a 
trabalhar esses temas em um ambiente baseado em nuvem, 
auxiliando na implementação desses conceitos na aplicação. 


OAuth 2.0 


OAuth 2.0 é o protocolo padrão de indústria com foco em 
autorização. Por meio dele conseguimos atingir o que conhecemos 
como autorização delegada. Por exemplo, um usuário pode permitir 
que um sistema A tenha acesso às suas informações e/ou execute 
alguma ação em seu nome em um sistema B, sem que seja 
necessário o compartilhamento de credenciais com o sistema A. 


Vejamos dois exemplos: 


1) Ao fazer seu cadastro em um novo banco digital (sistema A), o 
usuário pode convidar seus amigos do Facebook (sistema B) para 
também se juntarem ao novo banco. Para que o aplicativo do banco 
possa ter acesso aos amigos (dados do usuário no sistema B) do 
Facebook do usuário, uma permissão precisa ser concedida. 


2) Um aplicativo de dieta (sistema A) se propõe a postar (ação em 
nome do usuário) automaticamente uma mensagem no Twitter 
(sistema B) de seus usuários sempre que eles obtiverem bons 
resultados durante sua reeducação alimentar, convidando os 
seguidores desse usuário a também participarem do aplicativo. Para 
que isso aconteça, uma permissão precisa ser concedida. 


OAuth 2.0 possui uma terminologia bem específica e que vale a 
pena entendermos. Vejamos alguns atores comuns nos diversos 
fluxos possíveis desse protocolo: 


e Resource Owner é o usuário, sou eu ou você, são os 
indivíduos que são detentores dos dados e que permitirão 
acesso a eles ou que podem ter uma ação executada em seu 
nome. 


e Client é a aplicação que deseja acessar os dados de um 
usuário ou executar alguma ação em nome de um usuário. Nos 
exemplos acima, o aplicativo de dieta e o banco digital. 


e Resource Server é o componente onde os dados estão 
armazenados ou que expõe algum tipo de serviço (API) para 
que uma ação seja executada em nome do Resource Owner 
(usuário). 


e Authorization Server é o componente responsável por garantir 
que o usuário é quem ele realmente diz ser, por meio de 
autorização (consent) e revogação de um Client, emissão e 
validação de tokens em tentativas de acesso a dados ou 
execuções de ações em nome do Resource Owner (usuário). 
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Figura 14.5: Partes envolvidas em fluxos OAuth. 


Existem vários fluxos (também conhecidos como flows ou Grant 
Types) disponíveis no protocolo OAuth 2.0 para que um usuário 
permita que uma aplicação terceira tenha acesso a seus dados ou 
execute uma ação em seu nome. O fluxo mais comum é conhecido 
como Authorization Code e vamos explorá-lo em mais detalhes. 


É importante dizer que um fluxo bem-sucedido de OAuth busca 
obter o que conhecemos como access token. O access token pode 
ser entendido como uma chave que será entregue ao Client 
(aplicativo de dieta, banco digital etc.), que permitirá o acesso ao 
recurso desejado junto ao Resource Server. 


O Client deve possuir um client id e um client secret (a depender 
do fluxo OAuth necessário). São duas informações obtidas no 
momento do registro dessa aplicação junto à plataforma desejada 
(Facebook, Twitter, Microsoft etc.). O client id é a identificação desse 
Client junto à plataforma, e o client secret é uma espécie de senha 
(e, portanto, deve ser mantida em sigilo), que é utilizada em 
momentos específicos nos fluxos OAuth 2.0. 


O Client ainda deve fornecer uma redirect uri (também conhecida 
como call-back url) para o Authorization Server. Normalmente isso 
acontece durante o processo de registro dessa aplicação na 
plataforma. A redirect uri será utilizada durante o fluxo OAuth para 
devolver o controle ao Client. 


A seguir, um passo a passo para a obtenção de um access token: 


1. Usuário (Resource Owner) navega até a aplicação (Client). 

2. Em determinado ponto da aplicação, é necessário o acesso aos 
dados do usuário em uma plataforma específica, como o 
Facebook, por exemplo. 

3. O usuário é redirecionado para o Authorization Server (do 
Facebook, nesse caso) onde será apresentada uma tela de 
consentimento. 

o Aqui são apresentados os escopos requeridos pela 
aplicação bem como qual é a aplicação a que se deseja ter 
acesso. 

4. Usuário autoriza a aplicação a ter acesso aos escopos 
apresentados. 

5. O Authorization Server redireciona o usuário para a URL 
cadastrada previamente como redirect uri junto à plataforma. 

6. Com parte da URL redirecionada, é fornecido pelo Authorization 
Server um código conhecido como Authorization Code para o 
Client. 

o Esse código tem tempo de vida curto e só pode ser 
utilizado uma vez. Seu objetivo é ser utilizado para 
obtenção de um access token. 


7. O Client, de posse do authorization code via servidor (para nao 
expor o client secret), faz uma chamada para o Authorization 
Server, passando seus dados de client id, client secret e 
authorization code. 

8. A resposta do Authorization Server deve ser um access token. 

9. O access token será apresentado posteriormente ao Resource 
Server para a obtenção dos dados necessários. 


Os escopos são os delimitadores de acesso. É sempre prudente 
validar na tela de consentimento se a aplicação em questão não 
está solicitando mais permissões do que é realmente necessário. 
Por exemplo, se a aplicação precisa de acesso aos seus contatos 
(amigos), não faz sentido que ela peça autorização para o escopo 
que permite que ela faça um post em seu mural. 


O access token normalmente é um conjunto de caracteres 
arbitrários e que só faz sentido para o Authorization Server (que foi 
quem o gerou). Internamente o Authorization Server sabe que esse 
conjunto de caracteres é uma permissão concedida pelo usuário x, 
com os escopos y para a aplicação (Client) z. 


OpenID Connect 


Na seção sobre OAuth 2.0, percebemos que o protocolo foca no 
aspecto de autorização, mas e o componente de autenticação”? 
Além de autorizar, como podemos também autenticar um usuário 
em um fluxo como o descrito na seção anterior? Aqui entra o 
OpenID Connect. 


O OpenID Connect é uma camada simples de identidade que atua 
em cima do protocolo OAuth 2.0. Ele permite que aplicações 
verifiquem a identidade de um usuário com base na autenticação 
realizada por um Authorization Server e na obtenção de dados 
básicos do perfil do usuário. 


Um fluxo bem-sucedido de OpenID Connect deve fornecer o 
chamado id token. Se um access token pode ser considerado uma 


chave que da acesso a recursos no Resource Server, o id token 
pode ser entendido como um crachá, de onde a aplicação pode ler 
dados do usuario, como nome, cargo etc. 


O id token não é um conjunto de caracteres arbitrários, na verdade é 
um conjunto de caracteres muito bem estruturado, justamente para 
podermos ter a capacidade de abrirmos esse token e acessarmos 
as informações do usuário diretamente, sem precisarmos de uma 
nova comunicação com uma API, por exemplo. É um token 
autocontido. 


É utilizado o padrão JSON Web Token ou JWT para a construção 
do token, que é um formato específico para encoding de 
informações do tipo chave/valor altamente compacto (o que é 
excelente, dado o ambiente em que ele circula, ou seja, HTTP) e 
com capacidades de segurança. O token pode ser assinado 
digitalmente, seja de modo simétrico ou assimétrico. 


Como vimos anteriormente, nós temos a chamada autorização 
delegada com o access token. Com o id token, podemos obter o que 
chamamos de autenticação delegada. Podemos permitir que 
nossos usuários façam login em nossos sistemas através de algum 
provedor de identidade (Identity Provider ou IdP). Por exemplo, os 
usuários podem se autenticar em nossos sistemas com suas contas 
do LinkedIn, pois o LinkedIn (assim como outros Identity Providers) 
suporta o OpenID Connect. 


O fluxo é praticamente igual ao que vimos anteriormente na seção 
sobre OAuth 2.0, a diferença é que, além dos escopos necessários 
de autorização, devemos solicitar permissão ao escopo openid. 
Dessa forma, além de o Authorization Server devolver um 
authorization code, ele também vai devolver um id token. E você 
pode utilizar os dados contidos no id token para dar as boas-vindas 
ao usuário utilizando seu nome, por exemplo. 
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Figura 14.6: Fluxo com id_token. 


14.4 Como implementar o Azure AD B2C 


Nesta seção, veremos como integrar a aplicação ao Azure AD B2C. 
Iniciaremos com a preparação do ambiente e algumas 
configurações adicionais, depois realizaremos a configuração da 
aplicação e veremos como adicionar provedores de identidade 
externos para a integração. 


Preparação do ambiente 


O primeiro passo será a criação de um novo tenant no Azure AD 
B2C. 


Para isso, vamos efetuar o login no portal e acessar a pagina de 


criação de recursos no portal do Azure. Na caixa de busca, digite 
Azure Active Directory B2C. 


Home > 
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Figura 14.7: Criar um novo tenant do Azure B2C. 


Ao selecionar o item, iniciaremos o processo de criação de um novo 
tenant. 


Home > New > 


Azure Active Directory B2C x 


Microsoft 














Microsoft 


A Azure Active Directory B2C[ q sacra 
d 


Overview Plans Usage Information + Support 





Customer Identity and Access Management (CIAM) in the cloud 


Azure Active Directory (AD) B2C is a highly available and global identity management service for your customer-facing applications, that easily integrates across mobile and 
web platforms and scales to hundreds of millions of identities. Enable your customers and consumers to log on to your applications through fully customizable experiences, 
whether they use an existing social account or create new credentials. With Azure AD B2C, you can: 


e Protect your customers’ identities 

e Enable login with social media identities 

e Customize user experiences 

e Pay only for what you use on a per-Monthly Active User (MAU) basis 


Get started today with your free tier of 50,000 monthly active users (MAUs). 


Multi-Factor Authentication (MFA) activity is billed separately and is not included in the free tier. 


Figura 14.8: Opção novo tenant. 


Vocé podera criar um novo tenant ou criar um link com um tenant ja 
existente na sua organização. No caso, vamos criar um novo. 


Create new B2C Tenant or Link to existing Tenant 


b Za a new Azure AD B2C Tenant. © 





? Link an existing Azure AD B2C Tenant to my Azure subscription. © 





Figura 14.9: Configurações básicas. 


Selecionando a criação de um novo tenant, as seguintes opções 
serão exibidas. 


Home > New > Azure Active Directory B2C > Create new B2C Tenant or Link to existing Tenant 


Create a tenant x 


Azure Active Directory 
*Basics *Configuration Review + create 


Directory details 


Configure your new directory 


Organization name * © | Contoso Organization | 
Initial domain name * ©) contosoorg | 

.onmicrosoft.com 
Country/Region © | United States Vv | 





Q Datacenter location - United States 


Datacenter location is based on the country/region selected above. Azure Active Directory B2C 
service is available worldwide. 


Review + create < Previous | Next : Review + create > 


Figura 14.10: Opções de criação. 


Basta informar agora o nome da organização, seu prefixo de 
domínio e a localização. Com isso já podemos confirmar e criar a 
nova organização. 


Policies 


Uma configuração muito interessante que pode ser efetuada com o 
Azure AD B2C é a implementação de políticas para fluxos de 
usuários (User Flows). 


Com essa funcionalidade, é possível customizar fluxos importantes, 
como o fluxo de registro de novos usuários ou mesmo o fluxo de 
Login e Logout, o que permite a coleta de informações 
customizadas. 


Para efetuar essa customização, a partir da tela principal do recurso 
Azure AD B2C, selecionamos a opção User Flows e, nessa tela, 


selecionamos a opção + New user flow, como mostra a imagem a 
seguir. 
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Figura 14.11: Criação de um User Flow. 


A seguir, podemos escolher uma das opções detalhadas. 


Home > Azure AD B2C 


Create a user flow 


User flows are predefined, configured policies that you can use to set up authentication experiences for your end users. Select a user flow type to get started. Learn more. 


Select a user flow type 





Sign up and sign in Eza Profile editing » Password reset Q Sign up 


Enables a user to create an account Enables a user to configure their Enables a user to choose a new + Enables a user to create a new 
or sign in to their account. user attributes. password after verifying their account. 
email. 


Sign in Sign in using resource owner 
Pp Pp 


Enables a user to sign in to their password credentials (ROPC) 


account. Enables a user with a local account 
to sign in directly in native 
applications(no browser required). 


Figura 14.12: Detalhes do User Flow. 


Sign up and sign in permite customizar os fluxos de criagao de 
nova conta e autenticação. Profile editing permite customizar o 
fluxo de edição de perfil do usuário. Password reset permite 
customizar o fluxo de alteração de senha. Sign up permite 
customizar o fluxo de criação de nova conta. Sign in permite 
customizar o fluxo de autenticação. Sign in using resource owner 
password credentials (ROPC) permite customizar o fluxo para que 
os clientes utilizem sua senha de contas locais para efetuar a 
autenticação. 


Neste cenário, ao escolhermos o fluxo Sign in, podemos customizar 
as informações seguintes: 


e O provedor de identidade que será utilizado para autenticação. 

e Se utilizaremos ou não um provedor social. 

e Habilitação da autenticação multifator. 

e E, por fim, quais atributos dos usuários e claims serão colhidos 
durante a assinatura e posteriormente entregues durante o 
processo de login. Falaremos um pouco mais adiante sobre a 
questão de claims e sua utilização. 


Durante o processo de criação da política, é importante definirmos 
se a política de autenticação multifator estará habilitada ou não, e 
também podemos definir se os usuários são obrigados a optar por 
ela ou não, ou seja, essas configurações ficam a cargo do Azure AD 
B2C e não do provedor de identidade, pois elas podem variar de 
aplicação para aplicação. 


Note também que para que possamos escolher um provedor de 
identidade social é necessário que se faça também sua associação 
com nosso diretório. Detalharemos esse processo na seção Adição 
de providers comuns. 


Customização de layout 


Agora que falamos um pouco sobre como customizar o fluxo de 
login de um usuário, você deve estar se perguntando: é possível dar 


a tela de login de usuarios a cara da minha empresa quando utilizo 
o meu diretório de usuario? 


A resposta é sim. Você pode customizar as telas de interação com 
os usuários com sua identidade visual. Para isso, podemos utilizar 
uma maneira mais simplificada e uma maneira avançada. 
Começaremos pela maneira simplificada. 


O jeito mais fácil de efetuar a customização visual é configurar as 
opções de Branding. No portal do Azure, na página de recursos do 
Azure AD B2C, podemos escolher a opção Company Branding e 
customizar itens, como: 


e Imagem de fundo do site. 

e Imagem de banner. 

e Podemos customizar o texto sugerido na caixa de nome de 
usuário durante o login. 

e Texto da pagina de assinatura. 

e Cor de fundo do site de assinatura. 

e Logo da empresa a ser mostrado na página, com opção de 
tema claro e tema escuro. 

e Opção de permanecer conectado durante o login. 


Mas caso deseje utilizar algo mais customizado, também temos a 
opção de configurar uma página de template para customização 
visual. Para utilizar essa opção, é necessária a criação de uma 
simples página html e uma folha de estilo css. Com esses arquivos, 
podemos iniciar nossa customização. 


Além da criação do template, é necessário que eles sejam expostos 
em um website estático. Para isso, dentre as opções que temos, 
utilizaremos um Azure Storage. Vamos criar uma conta de Azure 
Storage e criar um contêiner para Blobs. 


Nesse contêiner, o único requisito é habilitar o acesso anônimo 
somente para leitura nos Blobs. 


A seguir, para um requisito de segurança, habilitaremos acesso 
CORS para o nosso diretório. Selecione o menu CORS na página 
de recursos da sua conta de storage e preencha as informações: 


e Allowed origins - preencha com 

https://<meu tenant>.b2clogin.com . Não se esqueça de substituir 
«meu tenant> pelo tenant criado inicialmente. É necessário que o 
tenant seja preenchido com letras minúsculas. 

Allowed methods - selecione GET, PUT e OPTIONS. 

e Allowed origins - preencha com asterisco (*). 

Allowed headers - preencha com asterisco (*). 

e Max age - preencha com 200. 


Após isso, OS acessos a partir de outros aplicativos estarão 
permitidos apenas ao seu tenant, melhorando a segurança. 


O próximo passo então é a criação dos arquivos. Serão criados um 
arquivo de folha de estilo e uma página html que o referencia. Para 
isso, utilize o seu editor de preferência, crie um arquivo chamado 
style.css € preencha o arquivo com o exemplo a seguir. 


h1 { 
color: blue; 
text-align: center; 
} 
«intro h2 { 
text-align: center; 
} 
.entry { 
width: 300px ; 
margin-left: auto ; 
margin-right: auto ; 
} 
.divider h2 { 
text-align: center; 
} 
.create { 
width: 300px ; 
margin-left: auto ; 


margin-right: auto ; 


} 





Note que há referência no arquivo a itens comuns de css como h1 e 
algumas classes existentes. Essas classes são utilizadas pelos 
elementos inseridos pelo Azure AD B2C ao injetar o html em nossa 
página de template. A seguir, faça o upload do arquivo no contêiner 
criado anteriormente. 


Agora vamos criar a página html que referencia esse arquivo de 
folha de estilo. Para isso, crie um arquivo chamado custom-ui.html e 
insira o texto a seguir. 


<!DOCTYPE html> 
<html> 
<head> 
<title>Minha aplicação B2C</title> 
<link rel="stylesheet" href="https://seu- 
storage.blob.core.windows.net/seu-container/style.css"> 


</head> 
<body> 
<hi>Minha aplicação B2C</h1> 
<div id="api"></div> 
</body> 
</html> 





Neste arquivo, temos dois destaques. Primeiro, note a tag link, 
onde temos uma referência à conta de storage e ao arquivo criado 
anteriormente. Segundo, na tag body , você vai notar que existe um 
div cujo id é api. O Azure AD B2C utiliza esse elemento para injetar 
em tempo de execução os campos necessários durante a utilização. 


Realize o upload desse arquivo para o contêiner criado 
anteriormente. 


A seguir, no portal do Azure, acesse a página de recursos do seu 
Azure AD B2C e, em User Flows, selecione o fluxo criado 
anteriormente de Sign up and Sign in. Você verá a opção Page 
layouts, onde poderá optar por habilitar o uso de conteúdo 
customizado e poderá indicar o caminho da página desejada. 


Home > Azure AD B2C 


D Search (Ctrl+/) 
sa Overview 


Settings 

ili Properties 

E Identity providers 
E User attributes 
E3 Application claims 


B 
* API connectors 
Customize 


Page layouts 


E Languages 


rg B2C 1 myapp | Page layouts 
Sign up and sign in (Re n 


> Run user flow Save x Discard E Template 


Ci} Got a second? We would love your feedback on customizing user flows -> 


Select a page to customize it’s appearance. You can provide your own html and css to add your own branding and layout. Learn more 


Layout name Custom page 


Unified sign up or sign in page 


Use custom page content No 














Se 
Custom page URI* (D | https://seu-storage.blob.core.windows.net/seu-container/custom-ui.html 
Page Layout Version (Preview) ©) 2.1.0 - Current WV | Learn more about Page Layout versions. 


Figura 14.13: Page Layouts. 


A seguir você pode selecionar Run user flow para realizar um teste 
e ver sua página customizada sendo chamada durante o processo 


de autenticação. 


Customização de idioma 


Outra funcionalidade muito interessante que temos no Azure AD 
B2C é o suporte a múltiplos idiomas. Você pode configurar um ou 
mais idiomas para sua aplicação. Para isso, basta acessar a opção 
Languages do recurso e habilitá-la selecionado a opção Enable 
language customization. 


Home > Azure AD B2C > B2C_1_myapp 


® B2C_1_myapp | Languages 


Sign up and sign in (Recommended) 





| D Search (Ctrl+/) | d E Run user flow GO Enable language customization Q Got feedback? 


o i ENR 2 dre 
GO MO OO Enable language customization for the best experience. See the documentation for the language customization feature. > 
Settings 

You can configure your user flow to support multiple languages. You can add your own custom language or use the langu: 


I; . 
ili Properues any language. Learn more about language customization. 


Ra, Identity providers 





All Configured 
&=) User attributes — 








Application claims Name Locale Default 





* 
4? API connectors 


Customize 
E Page layouts 


E Languages 


Figura 14.14: Configuração de múltiplos idiomas. 


Após selecionar essa opção, uma lista de idiomas compatíveis sera 
exibida. Note que você pode inclusive incluir um novo idioma caso 
deseje ou selecionar um da lista já preexistente. Vamos selecionar 
na lista a opção português (Brasil). 


pt-BR x 
Jages português (Brasi 


Q Got feedback? 
Upload language resources for each language for a page if you 
would like to customize the strings. For custom languages you will 
have to provide the translations for all the strings. Learn more 
about language customization. 


Enabled 


Page-level resource files 


“ Blocked page 


Download defaults (pt-BR) 
errea 


Upload new overrides 


Select a file 


ba Unified sign up or sign in page 


Figura 14.15: Idioma Portugués. 


Caso deseje, podemos habilitar esse idioma selecionando a opção 
Enabled e customizar as várias seções apresentadas. Para isso, O 
primeiro passo é efetuar o download do arquivo padrão e, em 
seguida, podemos customizar e realizar o update com as alterações. 


Ou seja, além de alterar o idioma, podemos também customizar 
todas as mensagens apresentadas livremente. 


Claims 


Claims podem representar características e são obtidas a partir dos 
atributos dos usuários do diretório, como nome, e-mail, idade, nível 
de permissão (papel) etc. 


No Azure AD B2C, temos uma lista de atributos predefinidos mas, 
caso seja necessário, também podemos criar uma lista 
customizada. Esses mesmos atributos podem ser selecionados para 
serem informados durante os fluxos do usuário e retornados à 
aplicação, nesse caso, como uma claim da aplicação. 


Por exemplo, podemos pedir que o usuario informe o tamanho da 
camiseta que ele utiliza durante o cadastro. Essa informagao sera 
armazenada em um claim e podera ser acessada sempre. 


Adicionalmente, as claims também são utilizadas para validação da 
autenticidade dos dados dos usuários. Existe um conjunto de claims 
que é disponibilizado automaticamente pelo Azure AD B2C para que 
protocolos como OAuth2 e Openld possam ser utilizados, mas é 
importante reforçar que essas claims não devem ser alteradas ou 
removidas para um perfeito funcionamento do fluxo de integração. 
Listamos essas claims a seguir: 


Audience - identifica o destinatário pretendido do token. 

Issuer - identifica o serviço emissor (STS) que constrói e 
retorna o token. 

Issued at - data e hora de emissão do token. 

Expiration time - data e hora de expiração do token. 

Not before - horário de início de validade do token, geralmente 
é o mesmo da emissão. 

Version - versão do token ID. 

Code hash - código de validação de autenticidade do token. 
Access token hash - código de validação do token de acesso. 
Nonce - estratégia utilizada para reduzir ataques de reprodução 
de token. 

Subject - item de identificação do propósito do token. Não pode 
ser alterado após a criação. 

Authentication context class reference - utilizado somente 
com políticas mais antigas, mantido por compatibilidade. 

Trust framework policy - nome da política utilizada na criação. 
Authentication time - hora que o usuário inseriu credenciais 
pela última vez. 

Scope - permissões concedidas ao recurso pelo token. 
Authorized party - ID do aplicativo que iniciou a solicitação. 


14.5 Configuração da aplicação 


Após as configurações básicas do nosso Azure AD B2C, chegou a 
hora de configurar nossa aplicação. 


Para adicionar uma nova aplicação, é necessário primeiro criar um 
registro dela e, para isso, selecionamos a opção App registrations. 


Home > Azure AD B2C 


E Azure AD B2C | App registrations d x 
EEE 






All applications Owned applications Applications from persor 


Display name Application (client) ID Created on Certificates & secrets 





Figura 14.16: Registro de uma aplicação. 


Selecionamos a opção + New registration e informamos os detalhes 
da aplicação: 


e Name: Nome da aplicação. 
e Supported account types: as opções são: 
o Account in this organization directory only - apenas 
usuários desta organização. 
o Accounts in any organizational directory - qualquer usuário 
Azure AD. 
o Accounts in any identity provider or organizational directory 
- qualquer usuário de Azure AD ou qualquer outro provedor 
de identidade confiável. 
e Redirect URI - caso seja uma aplicação web, configura o 
endpoint de recepção dos tokens de autorização. Para 


configurar nossa aplicação, a eShopWeb, já incluímos a URI 
https://localhost:<minha porta>/signin-oidc. 

e Grant admin consent to openid and offline access permissions - 
permite a utilização do protocolo openid e a renovação de 
tokens de permissão. 


Após a criação da aplicação, será gerado um id único para a 
aplicação que pode ser acessado a partir da listagem de aplicações 
ou a partir da tela de overview da aplicação desejada. Esse id será 
utilizado para o registro do provedor. Além disso, podemos 
customizar a seção de Branding e a aparência das telas de login e 
assinatura. 


Na seção Authentication, podemos verificar que tipo de autenticação 
foi selecionada e alterar quais tipos de aplicação chamarão essa 
tela. 


EGOZ MORAR] Configure platforms x 
9 MSA_App1 | Authentication d 


Web applications 








P Search (Ctrl+/ Q Got feedback? 
Web Single-page application 

E Overview ES 

Platform configurations Build, host, and deploy a web server Configure browser client applications and 
Integration assistant | Preview application. .NET, Java, Python progressive web applications. Javascript 

The web or mobile and desktop applications that ut 
Manage authenticating users. Depending the targeted platfor ice, at 

redirect URIs, specific authentication settings, or platform specific fields. 
E Branding 
nene F Add a platform Mobile and desktop applications 
? Certificates & secrets e ios / macOS Gu Android 
> API permissions Supported account types Objective-C, Swift, Xamarin Java, Kotlin, Xamarin 
@ Expose an API Who can use this application or access this API? 
E Owners © Accounts in any identity provider or organizational directory (1 

most common option for apps that are exposed to your 

MM Manifest ure AD B2C user flows. This option enabl 





s. This optior Mobile and desktop 
icrosoft, Facebook, Google, Twitter, or b applications 





Support + Troubleshooting 
@ Troubleshooting properties may cause errors for personal acc 


Advanced settings 


Figura 14.17: Tipos de autenticação. 


Dependendo do tipo de aplicação, pode ser necessária a 
configuração de segredos ou certificados para a troca de 
informações. Por exemplo, para sua aplicação mobile ou desktop, 
podemos configurar um segredo único da aplicação para 
autenticação, sem necessidade da autenticação do usuário. Isso 


pode ser feito por meio de uma senha de autenticação da aplicação, 
secret ou por meio de autenticação utilizando um certificado. Para 
efetuar essas configurações, podemos acessar a aba Certificates & 
secreis. 


Home > MSA App1 


? MSA_App1| Certificates & secrets € 


P Search (Ctrl+/) « Q Got feedback? 


E Overview Credentials enable applications to identify themselves to the authentication service when receiving tokens at a web addressable location (using an HTTPS scheme). We 
recommend using a certificate instead of a client secret for client credential scenarios when authenticating against Azure AD. Please note certificates cannot be used to 


# Integration assistant | Preview authenticate against Azure AD B2C 


Manage 
E Branding Certificates 
D Authentication Certificates (also referred as public keys) can be used as secrets to prove application's identity when requesting an Azure AD token. Certificates cannot be used to request 


Azure AD B2C tokens. We recommend using a certificate for client credential scenarios when authenticating against Azure AD. Click here to manage certificates for custom 

? Certificates & secrets policies. 
> API permissions z P 
A T Upload certificate 


@ Expose an API 
Thumbprint Start date Expires 


E Owners 


E No certificates have been added for this application 
E Manifest 


Support + Troubleshooting 


d Troubleshooting Client secrets 


A secret string that the application uses to prove its identity when requesting a token. Also can be referred to as application password. 


+ New client secret 
Description Expires Value 


MEA secret 12/31/2299 gre E 


Figura 14.18: Configuração de segredos ou certificados. 


Caso sua aplicação exponha alguma API de integração, podemos 
também configurar permissões de acesso para outras aplicações 
existentes. Isso pode ser feito acessando a aba API permissions. 


Home > MSA_App1 


-æ MSA_App1| API permissions x 
O Search (Ctrl+ © Refresh | Q Got feedback? 


Configured permissions 
Applications are authorized to call APIs when they are granted permissions by users/admins as part of the consent process. The list of configured permissions should include 
bout 


all the permissions the application needs. Learn more abou! 


Admin consent req... Status 





> API permissions 





O Expose an AP! 


H Owners 


EH Manifest 


Support + Troubleshooting 


& Troubleshooting 


Figura 14.19: Permissões de acesso para outras aplicações. 


Nessa tela, podemos escolher qual o tipo de acesso, quais itens são 
permitidos e podemos também escolher como expor nossas APIs 
customizando os scopes necessários para integração via OpenID. 
Vamos então configurar nosso aplicativo eShopOnWeb para utilizar 
o tenant, que acabamos de configurar. Precisaremos executar 
alguns passos: 


e Remoção de referências ao provedor de identidade existente. 

e Adição dos pacotes nugets para referência do provedor de 
identidade do Azure AD B2C. 

e Configuração da seção do appSettings destinada a 
configuração do tenant e registro do aplicativo. 

e Adequações de código para refletir as novas configurações. 


Remoção de referências ao antigo provedor de identidade 


Foram removidos os pacotes nugets abaixo: 


Microsoft.AspNetCore. Identity. EntityFrameworkCore 
Microsoft.AspNetCore.Identity.UI 


Microsoft.AspNetCore. Authentication. JwtBearer 
System. IdentityModel.Tokens.Jwt 





Removemos também as views € OS controllers listados abaixo: 


src\Web\Areas\ * 
src\Web\Views\Manage\ * 


src\Web\Controllers\ManageController.cs 








E ee 
4 \& Areas 
EI View in Browser (Firefox) Ctrl+Shift+W 4 ‘| Identity 
Browse With... 4 t Pages 
EE ; 4 &) Account 


a [8] _Viewlmports.cshtml 


Scope to This > a [E] ConfirmEmail.cshtml 

New Solution Explorer View b a cs ConfirmEmail.cshtml.cs 
e b eli Login.cshtml 

D View History... p a C* Login.cshtml.cs 

Exclude From Project b ale) Logout.cshtml 

b ac Logout.cshtml.cs 

d Cut Ctrl+X > eli Register.cshtml 
OI Copy Ctrl+C b ac Register.cshtml.cs 

Paste Ctrl+V a E) _ValidationScriptsPartial.cshtml 
X Delete Del a [E] _Viewlmports.cshtml 
Bate e Sl _ViewStart.cshtml 


b a C* IdentityHostingStartup.cs 
a Configuration 
a) Controllers 
a DD Extensions 
a DD Features 


Copy Full Path 
@ Open Folder in File Explorer 





Properties Alt+ Enter 


Le a, amo Aa 





Figura 14.20: Remoção da pasta Areas. 


b a Account 


| 4 at! Views 
“= Manage 





EI View in Browser (Firefox) Ctrl+Shift+W a E _Layout.cshtml 
Browse With... a [e] _ManageNav.cshtml 
Add R a [8] _StatusMessage.cshtml 
a [8] _Viewlmports.cshtml 
Scope to This a [8] ChangePassword.cshtml 


a [2] Disable2fa.cshtml 

o EnableAuthenticator.cshtml 

a [E] ExternalLogins.cshtml 

a le] GenerateRecoveryCodes.cshtml 
b a c* ManageNavPages.cs 


New Solution Explorer View 
À View History... 


Exclude From Project 






d Cut Cine a le] MyAccount.cshtml 
O! Copy Ctrl+C a le] ResetAuthenticator.cshtml 
Paste Ctrl+V a [8] SetPassword.cshtml 
X Delete Del a |e] TwoFactorAuthentication.cshtml 
ST Order 
Rename F2 


af) Shared 

a [E _Viewlmports.cshtml 

a [e] _ViewStart.cshtml 
appsettings.Development,json 
appsettings.Docker.json 


Copy Full Path 
@ Open Folder in File Explorer 





d Properties Alt+ Enter 


Figura 14.21: Remogao da pasta Views/Manage. 


Adição do pacote nuget para o novo provedor de identidade e 
configuração 


Foi adicionado o pacote nuget: 


Microsoft.AspNetCore.Authentication.AzureADB2C.UI 





Para instalar o pacote, basta executar o comando abaixo na janela 
Package Manager Console do Visual Studio: 


Install-Package Microsoft .AspNetCore.Authentication.AzureADB2C.UI 





Configuração da seção do appsettings.json 


Foram adicionados ao arquivo de configuração, appsettings.json, OS 
seguintes itens: 


"AzureAdB2C": { 
"Instance": "https://<meu_tenant>.b2clogin.com/tfp/", 
"ClientId": "<meu_clientid>", 
"CallbackPath": "/signin-oidc", 


"Domain": "<meu_tenant>.onmicrosoft.com", 
"SignUpSignInPolicyId": "B2C_1 myapp”, 
"ResetPasswordPolicyId": "B2C_1 reset" 





Adequação de código para novas configurações 


Na aplicação original, a verificação de usuário logado era feita 
através do seguinte código: 


_SignInManager.IsSignedIn(HttpContext.User ) 





As referências ao código acima foram alteradas para: 


User. Identity. IsAuthenticated 





As referências ao campo somente leitura e privado abaixo, também 
devem ser removidas da aplicação: 


private readonly SignInManager\<ApplicationUser\> \_signInManager; 





Além disso, ao trazer informações do usuário, fazemos uma alterção 
para que essa informação seja obtida através dos claims 
retornados, utilizando como exemplo o código abaixo para a captura 
do identificador do usuário e seu nome: 


User.Claims.Where(c => c.Type == ClaimTypes.NameIdentifier) 
.Select(c => c.Value).SingleOrDefault() 


User.Claims.Where(c => c.Type == ClaimTypes.GivenName) 
.Select(c => c.Value).SingleOrDefault() 





Altere o arquivo _LoginPartial.cshtml para que fique como abaixo. No 
código, avalia-se se o usuário está autenticado olhando para o 
atributo context .User. Identity . Caso o usuário já esteja autenticado, 
IsAuthenticated exibe informações do usuário, caso contrário, exibe 
o botão Sign-in para que o usuário possa logar na aplicação: 





@using System.Security.Claims 
@if (Context.User.Identity.IsAuthenticated) 


{ 


<section class="col-lg-4 col-md-5 col-xs-12"> 
<div class="esh-identity"> 
<form asp-area="AzureADB2C" asp-controller="Account" asp- 
action="SignOut" method="get" id="logoutForm" class="navbar-right"> 
<section class="esh-identity-section"> 
<div class="esh-identity- 
name" >@User.Claims.Where(c => c.Type == ClaimTypes.GivenName).Select(c 
=> c.Value).SingleOrDefault()</div> 
<img class="esh-identity-image" 
src="~/images/arrow-down. png" > 
</section> 
<section class="esh-identity-drop"> 
@if (User.IsInRole("Administrators") ) 
{ 
<a class="esh-identity-item" 
asp-page="/Admin/Index"> 
<div class="esh-identity-name esh- 
identity-name--upper">Admin</div> 
</a> 
} 
<a class="esh-identity-item" 
asp-controller="Order" 
asp-action="MyOrders"> 
<div class="esh-identity-name esh-identity- 
name--upper">My orders</div> 
</a> 
<a class="esh-identity-item" 
href="javascript:document.getElementById('logoutForm' ).submit()"> 
<div class="esh-identity-name esh-identity- 
name--upper">Log Out</div> 
<img class="esh-identity-image" 
src="~/images/ logout. png"> 
</a> 
</section> 
</form> 
</div> 


</section> 


<section class="col-lg-1 col-xs-12"> 
@await Component. InvokeAsync("Basket”, User.Claims 
-Where(c => c.Type == ClaimTypes.NameIdentifier) 
.Select(c => c.Value).SingleOrDefault() ) 
</section> 
} 
else 
{ 
<section class="col-lg-4 col-md-5 col-xs-12"> 
<div class="esh-identity"> 
<section class="esh-identity-section"> 
<div class="esh-identity-item"> 
<a class="esh-identity-name esh-identity-name-- 
upper" asp-area="AzureADB2C" asp-controller="Account" asp- 
action="SignIn">Sign in</a> 


</div> 

</section> 
</div> 
</section> 


<section class="col-lg-1 col-xs-12"> 
@await Component. InvokeAsync("Basket") 
</section> 





A seguir, substitua a autenticação baseada em cookies pela 
autenticação utilizando o Azure AD B2C. Para isso, substitua, no 
arquivo startup.cs , O trecho de código a seguir: 


services.AddAuthentication( 
CookieAuthenticationDefaults.AuthenticationScheme) 
.AddCookie(options => 
{ 


options.Cookie.HttpOnly = true; 
options.Cookie.SecurePolicy = CookieSecurePolicy.Always; 
options.Cookie.SameSite = SameSiteMode.Lax; 


}); 


services.AddIdentity<ApplicationUser, IdentityRole>() 
.AddDefaultUI() 
.AddEntityFrameworkStores<AppIdentityDbContext>() 
.AddDefaultTokenProviders(); 


services 
.AddScoped<ITokenClaimsService, IdentityTokenClaimService>(); 





Pelo código abaixo: 


services 
.AddAuthentication(AzureADB2CDefaults.AuthenticationScheme) 


.AddAzureADB2C( 
options => Configuration.Bind("AzureAdB2C", options)); 





Adição de providers comuns 


Novos provedores de identidade podem ser adicionados como 
confiáveis ao seu tenant do Azure AD B2C. Para isso, basta acessar 
a tela /dentity Providers que serão exibidos os provedores 
disponíveis para integração, como podemos ver na tela abaixo. 


Home > Azure AD B2C 


Ba Azure AD B2C | Identity providers 
Saas 


P Search (Ctrl+/) < + New OpenID Connect provider 9 Got feedback? 
& Overview 
Identity provider Configuration 
Manage 
D Amazon 


= App registrations 
E E E Facebook 
E Applications (Legacy) 
O GitHub (Preview) 
a Identity providers 


G Google 
«> API connectors (Preview) fin] 
Linkedin 
ill Company Branding 
f R Local account Email 


E User attributes 
R Users 


E Roles and administrators 


a Microsoft Account 
O QQ (Preview) 
D Twitter 


Policies D WeChat (Preview) 


«a User flows & weibo (Preview) 


GO Identity Experience Framework 


Figura 14.22: Provedores de identidade. 


Para finalizar essa configuração, precisaremos criar um secret que 
será utilizado para autenticação da aplicação cliente com o Azure 
AD B2C. Para isso, na tela de registro de aplicativo do Azure AD 
B2C, selecione a aba App Registrations. Selecione o aplicativo 
criado anteriormente e selecione a aba Certificates & secrets. Crie 
um novo segredo selecionando + New client secret e, para isso, 
adicione uma descrição e selecione o período desejado para 
expiração do segredo (o valor padrão é de 6 meses). 


Após a configuração da nossa aplicação, podemos ver que agora, 
além de podermos utilizar o login com uma conta do nosso próprio 
tenant, temos também a opção de realizar login utilizando uma 
conta Microsoft. 


Sign in with your email address 


Email Address 


Password 


Forgot your password? 


Sign in 


Don't have an account? Sign up now 


Sign in with your social account 





Figura 14.23: Nova tela de login com Azure AD B2C. 


No decorrer deste capítulo, vimos algumas informações básicas de 
identidade, iniciando com o entendimento de alguns conceitos 
básicos como identidade, autenticação e autorização. Depois, vimos 
um histórico de implementações comuns para aplicações .NET, 


entendemos o funcionamento do Azure AD e diferentes integrações 
como Azure AD B2B e Azure AD B2C. Finalmente, revisamos o 
conceito dos protocolos OAuth e Open ID e implementamos a 
integração da nossa aplicação com o Azure AD B2C, possibilitando 
a integração não apenas com identidades da aplicação, mas 
também a utilização de provedores de identidade externos. 


CAPITULO 15 
Resumo 


Assim chegamos ao final do nosso livro, o que de forma alguma 
significa que esgotamos o assunto. Mostramos como mover 
aplicações de ambientes on-premises para o Azure bem como as 
vantagens obtidas em relação a data centers próprios. 


15.1 Benefícios 


Após a modernização, obtivemos um uso mais eficiente de recursos 
devido à possibilidade de escalar a solução de acordo com a 
demanda em vez de pagar por recursos não utilizados. Percebemos 
que, ao utilizar soluções PaaS, foi possível concentrar esforços, que 
antes seriam gastos com provisionamento e manutenção de 
ambientes, em funcionalidades que agregam valor ao negócio. 


Evoluímos o ciclo de desenvolvimento aplicando práticas DevOps, 
como CI/CD, testes e monitoração, vimos também como empacotar 
a solução usando contêineres e como implantar a solução em 
clusters usando o Azure Kubernetes Services. 


15.2 Outros serviços que merecem ser 
explorados 


O Azure nos oferece uma ampla gama de serviços, não explorados 
neste livro, que agregam valor às aplicações enquanto nos ajudam a 


focar no negocio, economizando tempo no desenvolvimento, no 
provisionamento ou na gestao de recursos. 


Azure Front Door: é um ponto de entrada global e escalável que 
usa a rede de borda da Microsoft para disponibilizar aplicações web 
rápidas, seguras e altamente escaláveis. O Front Door trabalha na 
camada 7 (HTTP/HTTPS), usando o protocolo anycast com 
separação TCP e a rede global da Microsoft para aprimorar a 
conectividade em qualquer parte. Baseado no método de 
roteamento, é possível garantir que o Front Door direcionará as 
requisições dos clientes para o back-end mais rápido, próximo e 
com maior disponibilidade. O back-end de aplicação pode ser 
qualquer serviço exposto para a internet hospedado ou não no 
Azure. 


O Front Door oferece um conjunto amplo de métodos para 
roteamento de tráfego e monitoramento da saúde do back-end, que 
permite atender a diferentes necessidades de aplicação e cenários 
de tolerância a falhas. 

Similar ao Traffic Manager, o Front Door é resiliente a falhas, 
incluindo as falhas que atingem uma região inteira do Azure. A 
principal diferença entre o Front Door e o Traffic Manager é que este 
trabalha baseado em DNS enquanto aquele atua no nível do 
protocolo HTTP/HTTPS, podendo rotear requisições a partir de 
dados contidos nas mensagens. 


Azure API Management (APIM): possibilita a criação de gateways 
para APIs modernos e consistentes. API Management ajuda as 
organizações na publicação de APIs que permitam a parceiros 
externos e também desenvolvedores internos desbloquear o 
potencial de seus dados e serviços. Em todo o mundo, empresas 
buscam estender as suas operações na forma de plataformas 
digitais, criando novos canais e buscando novos clientes enquanto 
aprofundam o engajamento com os clientes já existentes. API 
Management oferece as competências centrais que garantem uma 
API bem-sucedida através do engajamento de desenvolvedores, 
descobertas de negócio, dados analíticos, segurança e proteção. 


Podemos usar o Azure API Management para lançar um programa 
completo de API a partir de qualquer back-end existente. 


Azure Content Delivery Network (CDN): é uma rede distribuída de 
servidores que armazenam o conteúdo em cache nos servidores de 
borda que estão próximos aos usuários finais, a fim de minimizar a 
latência. O serviço de CDN do Azure oferece aos desenvolvedores 
uma solução global de fornecimento rápido de conteúdo para 
usuários, armazenando em cache o conteúdo em nós físicos 
estrategicamente posicionados em todo o mundo. As vantagens de 
usar a CDN do Azure para entregar conteúdos de site da Web 
incluem: 


e Melhor desempenho e aprimoramento da experiência dos 
usuários finais, especialmente com aplicativos em que várias 
requisições são necessárias para carregar o conteúdo. 


e Grande dimensionamento para lidar melhor com alta carga 
instantânea, como no início de um evento de lançamento de 
produto. 


e Distribuição de solicitações de usuários e fornecimento de 
conteúdo de servidores de borda, assim menos tráfego é 
enviado ao servidor de origem. 
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